Splitting Network.URI from the network package

[Michael Snoyman]

On Mon, Aug 4, 2014 at 6:55 PM, Johan Tibell <johan.tibell at gmail.com> wrote:

> Hi Michael,
>
> I'm supportive of this (just as I've been in the past). We need to
> have network-uri added to the HP, which I don't think should be a
> problem as the API doesn't change with this split, assuming that the
> new maintainer agrees to follow the HP rules (e.g. don't add non-HP
> packages as dependencies, don't radical change the API without
> discussion.)
>
> I have a slight preference to use 2.6 as the network version number,
> as I'm saving 3.0 for something more juicy.
>
>
I have no objection to 2.6 instead of 3.0. I didn't feel strongly one way
or the other, I just wanted to make the proposal as concrete as possible.
Consider it amended to use 2.6 instead.


> > 1. Create a new package, network-uri, version 2.5.0.0, which exposes no
> modules and has an upper bound `network < 2.6.
>
> I'm sure there's something clever behind this empty package, but I
> don't quite understand it. How does this help. Note that depending on
> network-uri but not network will not let you use Network.URI in your
> code, as that module will be hidden.
>
>
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.


> > 2. Create a second release of network-uri, version 3.0.0.0, which
> provides the Network.URI module verbatim as provided by the network package
> today, and has a lower bound `network >= 3.0`.
>
> (And < X+1, as the HP follows the PVP.)
>

I really don't want this to turn into another PVP discussion. And I'm not
going to object to including an upper bound here if that's deemed
"required" for some reason (I only left it out of the proposal since it's
irrelevant to my point). All that said...

Can you name a single way in which an upper bound *actually* helps?
network-uri will not depend on any functionality in network itself[2], so
there's no way that a breaking change in network will possibly cause
network-uri to stop compiling. The *only* possibility is that network could
expose a module that conflicts with a module in network-uri. However:

1. That is not a protected situation by the PVP anyway; adding a new module
to a package is a minor version bump, so an upper bound wouldn't provide
protection.
2. I actually think we *should* have a guarantee that network never expose
a module that conflicts with network-uri. Better yet, I think there should
be an accepted standard that no two Haskell Platform packages export the
same module name. (I'm not actually proposing that here, it's clearly
separate than my main proposal.)

So if someone can articulate a good reason for an upper bound in
network-uri on network, please let me know. Again, if this is going to end
up blocking this proposal, I'd rather just include the upper bound.

Michael

[1] Two painful experiences for me were the network + network-bytestring
merge, and the blaze-html/blaze-markdown split. I'd like to try to avoid
that situation, and in my recent package merging, I've done so as much as
possible.
[2] If there *is* some dependency from the Network.URI module to the rest
of the network package, please let me know, I couldn't see one.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140804/6ff7d192/attachment.html>