Re: Splitting Network.URI from the network package

I don't think (but Andres can say more) that a simple non-nested flag should give the backtracker problems (bugs or increase the search space so much that it won't find a solution.) On Sun, Aug 10, 2014 at 3:22 AM, Edward Kmett wrote:

The problem with a flag based solution is it puts extra pressure on the backtracker in cabal, and when you pile enough of those up then you get things where cabal refuses to find a solution. Not for you, but for packages 20 dependencies later in the chain.

What I do with transformers-compat is I have multiple minor versions of the same package extant to work around bugs in the backtracker and then have separate point release that can work with transformers 0.2, one for transformers 0.3 and one for transformers 0.4, then users can depend on both transformers >= 0.2 and transformers-compat >= 0.3.3 and their code 'just works' regardless of which package is supplying the module.

On Wed, Aug 6, 2014 at 6:09 AM, Johan Tibell wrote:

...

On Mon, Aug 4, 2014 at 6:21 PM, Michael Snoyman wrote:

...

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

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries