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