On Mon, Aug 4, 2014 at 6:21 PM, Michael Snoyman
The idea is that users of Network.URI will be able to add a dependency along the lines of:
build-depends: network >= 2.5 && < 2.7, network-uri >= 2.5 && < 2.7
and work with both the pre- and post-split versions of the package, without any conditional compilation or cabal flags. I'm sensitive to adding any requirements of cabal flags, since (1) it clutters cabal files quite a bit[1], and (2) we just went through some painful cabal-install dependency solver issues around flags.
I agree that using flags to encode OR is a bit heavy weight. We should really support || in build-depends. For completeness, here's what a flag-based solution looks like. Assuming that network-uri-2.6 has the URI module and network-2.6 no longer has it we get this flag setup: flag network-uri description: Get Network.URI from the network-uri package default: True library if flag(network-uri) build-depends: network-uri >= 2.6 else build-depends: network < 2.6 If the user wants something else from network (e.g. Network.Socket) it would be flag network-uri description: Get Network.URI from the network-uri package default: True library if flag(network-uri) build-depends: network-uri >= 2.6, network >= 2.6 else build-depends: network < 2.6 Lets see if I understood your scheme correctly. We'd have * network-2.5: Has URI module. * network-uri-2.5: Doesn't have URI module. Depends on < network-2.6 (i.e. network-2.5 in this example). * network-2.6: Doesn't have URI module. * network-uri-2.6: Has URI module. Depends on network >= 2.6 (i.e. network 2.6 in this example). Given build-depends: network >= 2.5 && < 2.7, network-uri >= 2.5 && < 2.7 legal combinations of the above packages are * network-2.5 and network-uri-2.5, which gives URI through network, and * network-2.6 and network-uri-2.6, which gives URI through network-uri. There are two implications of this, which are slightly strange: * There's no point in anyone depending on only network-uri-2.5 (as it doesn't expose anything). * network-uri-2.6 and later will have to have a lower dependency on network forever, even though network-uri doesn't use anything from network (this is reflected when you discuss the upper bound in the context of the PVP later). I don't know if there's any other implications. Can anyone think of any? -- Johan