Splitting Network.URI from the network package

Tue Aug 12 12:44:51 UTC 2014

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