Splitting Network.URI from the network package

[Edward Kmett]

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 <johan.tibell at gmail.com> wrote:

> On Mon, Aug 4, 2014 at 6:21 PM, Michael Snoyman <michael at snoyman.com>
> 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140809/7f1953bc/attachment.html>