Splitting Network.URI from the network package

[Michael Snoyman]

On Wed, Aug 13, 2014 at 12:28 PM, Johan Tibell <johan.tibell at gmail.com>
wrote:

> 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).
>
>
I'd add in a very big "users will very likely not know the right way to put
in the build-depends correctly." This contrasts with your second con under
option 2. I think it's highly unlikely that users will think that using a
flag to indicate a conditional dependency is the obvious solution. Instead,
I'd imagine we'd end up in the situation where users put in a dependency on
both network and network-uri, it works on their systems, and then we get
lots of downstream breakage when someone with an older version of network
tries to build the package.


> *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).
>
> Can you clarify this point? I would imagine that network will no longer
have *any* dependency on text, so I don't see where this comes from.

>
>    - 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.)
>
> I think this is a bigger con with option 1. Teaching users about a strange
flag conditional is far more difficult IMO than saying "just depend on both
network and network-uri." Yes, both approaches have the potential create
downstream breakage, but I think this one is easier to educate about.


>
>    - network-uri-2.5 is an empty package, which might lead to slight
>    confusion for some users.
>
>
I'd consider that a *very* minor point. network-uri-2.5 would simply have a
note in its description field explaining why it exists, likely with a link
to this thread.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140813/5bd7f3e1/attachment-0001.html>