Splitting Network.URI from the network package

Tue Aug 12 12:59:30 UTC 2014

Just to be clear from my side: even if we were 100% certain that all issues
we've experienced in the past from the solver with flags would not exist
with the newest versions of cabal-install, I would still want to follow the
same proposal as I gave at the beginning of this thread, because forcing
every user of Network.URI to add conditionals to their cabal file is IMO
more painful than simply having two versions of the network-uri package
released.

The only modification to the proposal that I think would make sense would
be to have a single version of network-uri, and the exposing of the
Network.URI module be conditional on the version of network. But I'd rather
stick with the original proposal than encounter possibly unknown solver
bugs.

On Tue, Aug 12, 2014 at 3:44 PM, Johan Tibell <johan.tibell at gmail.com>
wrote:

> Is this still the case with cabal-install 1.20.0.3/1.18.0.5? We recently
> bumped the max backtracking limit by about 10x. My current understanding of
> the state of the solver is that as of the cabal-install versions I gave
>
>  * there are no known bugs that cause the solver to find a plan if there
> is one (if the backtracking limit isn't reached) and
>  * the backtracking limit is high enough for the packages we currently
> have on Hackage.
>
> If this isn't true please let me know and we'll look into it.
>
> If there's a problem I want to fix it at its source (i.e. in the solver)
> rather than trying too many workarounds in .cabal files. The latter leave
> residues that we have to live with for quite a long time. I'm happy to
> backport any solver fixes if it means we can have cleaner .cabal files.
>
>
> On Sun, Aug 10, 2014 at 4:30 PM, Edward Kmett <ekmett at gmail.com> wrote:
>
>> 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/20140812/11c5a8a1/attachment-0001.html>