On Mon, Aug 4, 2014 at 6:55 PM, Johan Tibell <johan.tibell@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.

_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries