Splitting Network.URI from the network package

[Duncan Coutts]

So it's true that using flags here is the standard solution (e.g. as
was used with the base split for a few years), so many (but not all)
users know this already.

I should also note (Andres: please correct me if I'm wrong) that as of
cabal-install 1.20, the cost in terms of backtracking for flags like
these is now quite small because choosing them is deferred as late as
possible. Edward: this should solve your problem with flags with
transformers, at least once 1.20 is widely used. It'd be great if you
could check that this is the case.

So overall it looks like both options work ok, and that there are not
very strong reasons either way.

If we pick option 2, it is inevitable that some people will use option
1 anyway, but that's probably ok. We think option 1 does not cause
problems for the solver (at least with cabal-install 1.20+, and works
with earlier but increases backtracking pressure).

Option 2 should solve the stated problem so long as users have
network-2.6 pre-installed from the HP (to avoid difficulties with
building it on windows). The false dependency in option 2 is a bit
unfortunate because it means you pull in network even if you only need
network-uri. Obviously in this specific case, that's not a big
practical problem because both should be pre-installed for HP users.
But it does point out that option 2 is not a general solution to
package splits.

Overall, on balance I think I'd go with option 1. Option 1 has the
benefit that it is our current standard solution to these problems
that at least some people know about. The main downside with option 1
is the rather verbose and non-intuitive syntax. We can focus our
development efforts on extending the dependency syntax to give us a
nicer general solution to package splits and merges. Option 2 while
superficially simpler would not help us longer term with educating
users on how to cope with these situations, since it's not a solution
that will work in general (the false dep will bite in other
situations). User education for option 2 would only help them with
this specific situation and not with other similar package splits.

So I think I'd recommend we continue to tell users about the current
(slightly ugly) standard solution, and work on adding better syntax.
An advantage of that approach is that we could have `cabal check`
suggest the use of the new syntax when it sees the existing (ugly)
pattern.

For reference, a bit more detail on the problem with the false dep in option 2:

> network-2.5 exposes Network.URI.
> network-2.6 no longer exposes Network.URI.
> network-uri-2.5 Exposes no modules. Depends on < network-2.6.
> network-uri-2.6 exposes Network.URI. Depends on network >= 2.6.

The problem is with network-uri-2.6 depending on network >= 2.6. This
is supposed to be the "new" state that we'd be in from then on, but
we're left with network-uri-2.6 depending on network, even though it
doesn't use it.

That dependency needs to be there because network-uri-2.6 conflicts
with network-2.5.

As I said, in this specific case it's not a major problem, but it
indicates we cannot take this approach in general for package splits
because it does not let us split to reduce dependencies (which is the
typical reason to want to split).

Thanks to Johan and Michael, Edward and others for setting out the
problem and a thoughtful discussion.

Duncan