Splitting Network.URI from the network package

Johan Tibell johan.tibell at gmail.com
Wed Aug 13 09:28:30 UTC 2014


I asked Duncan for some feedback, so here's a summary for his benefit:

First Michael's (and our) problem statement:

   - The network package is a pain to install on Windows for most users
   (especially new users), since it requires msys.
   - Most Windows users therefore install the Haskell Platform, avoiding
   the msys dependency.
   - The current release of HP installs text version 0.11.3.1. text is a
   dependency of parsec, and parsec is a dependency of network. Therefore, you
   can't build against a new version of text *and* use the network package
   without recompiling network, which as I mentioned is difficult.
   - A number of popular packages depend on newer versions of text. For
   example, since 0.8.0.0, aeson requires text version 1.1.0.0 or later. as
   does attoparsec since version 0.12.0.0.

The two options:

*Option 1: Users of Network.URI use a flag*

   - network-2.6 no longer exposes Network.URI.
   - network-uri-2.6 exposes Network.URI.

User who want only network-uri writes:

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 also wants network he/she adds it to the first build-depends
line.)

Cons:

   - More typing (an extra flag declaration, an if statement, and an extra
   build-depends line).
   - Could trigger possible unknown solver bugs (but there are no confirmed
   such bugs).

*Options 2: Users of Network.URI depend on both network and a specially
crafted network-uri*

   - network-2.5 exposes Network.URI.
   - network-2.6 no longer exposes Network.URI.
   - network-uri-2.5 Exposes no modules. Depends on < network-2.6.
   - network-uri-2.6 exposes Network.URI. Depends on network >= 2.6.

User who want network-uri (only) writes:

build-depends: network >= 2.5 && < 2.7, network-uri >= 2.5 && < 2.7

Cons:

   - network-uri has a false dependency on network (i.e. it doesn't
   actually need that package).
   - You can't build against a new version of text *and* use the
      network-uri package (this is the current problem we have with network in
      the problem description).
   - We need to teach users about the above special build-depends
   construction, just for use with the network and network-uri packages. Users
   who don't know of this special construction will still use a flag (and thus
   get a mix of cons from both approaches.)
   - network-uri-2.5 is an empty package, which might lead to slight
   confusion for some users.

Cheers,
  Johan


On Tue, Aug 12, 2014 at 2:59 PM, Michael Snoyman <michael at snoyman.com>
wrote:

> 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/20140813/285b88ef/attachment.html>


More information about the Libraries mailing list