Re: Splitting Network.URI from the network package

13 Aug 2014

      On Wed, Aug 13, 2014 at 2:35 PM, Johan Tibell 
wrote:
...
On Wed, Aug 13, 2014 at 11:39 AM, Michael Snoyman 
wrote:
...
On Wed, Aug 13, 2014 at 12:28 PM, Johan Tibell 
wrote:
*Options 2: Users of Network.URI depend on both network and a specially
...
...
crafted network-uri*
...
...
...
Cons:
...
- network-uri has a false dependency on network (i.e. it doesn't
   actually need that package).
   - You can't build against a new version of text *and* use the
      network-uri package (this is the current problem we have with network in
      the problem description).
Can you clarify this point? I would imagine that network will no
longer have *any* dependency on text, so I don't see where this comes from.
My apologies. Let me clarify. If the user doesn't already have a version
of network installed (e.g. via the HP), then building network is required
to build network-uri. This probably isn't a problem on Windows, if we
assume users already have an appropriate version of network through the HP.
It might be an inconvenience (e.g. longer build times) for users who don't
use the HP but still want to build network-uri (e.g for the maintainer of
network-uri :) ).
Thanks for the clarifications Duncan and Johan. Yes, we should add a con to
the option 2 that usage of network-uri will require network to be
available. I'd consider this a relatively low-impact con, since I highly
doubt there are many people out there who will want to use Network.URI but
not also want to use network- at least transitively.

Even after the arguments from Duncan and Johan, I still would prefer going
with option 2, because (1) I don't feel confident yet that all flag-related
issues in the dependency solver have been fixed (up until just two weeks
ago I was still answering user questions about those bugs), and (2) my
experience with the flag approach was that it was very tedious to work
with, and I remember seeing a lot of confusion among other packages as to
the right way to specify dependencies.

I still think that either option 1 or option 2 are better than the current
status quo, so I'd rather not let this issue become a sticking point in the
proposal. I'd say let's take a vote on option 1 or 2, and continue with the
discussion deadline for this proposal (which seems to have unanimous
support) of this Friday. Any objection?

Michael