Splitting Network.URI from the network package

[Johan Tibell]

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 <ekmett at gmail.com> 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 <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/20140810/11170d79/attachment.html>