Splitting Network.URI from the network package

[Edward Kmett]

The problem is more that there seem to be now packages that are within a
factor of 2 of the total amount of backtracking they can do, so it seems
pretty much every flag way down at the bottom of the package hierarchy
pushes something out past the limit.

I hear something from someone every time I add a flag. Take that for what
it's worth.

-Edward


On Sun, Aug 10, 2014 at 5:48 AM, Johan Tibell <johan.tibell at gmail.com>
wrote:

> 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/d2936683/attachment.html>