Hello. I consider the original proposal to be well founded and I support it. However, I started to think if there is anything we can improve about installation of network package itself? Maybe we can get rid of MSYS, at least for the end users of network package? How would that happen? The following plan came to my mind: 1. Select a single supported configuration (Windows version) 2. Execute a "normal" build with MSYS 3. Extract a configuration that was "discovered" by MSYS 4. Bake in the configuration into installation files to be used on Windows when MSYS is not present. There shouldn't be that many supported configurations on Windows. I think it is reasonable to do: 1. Windows XP 2. Windows 7 3. Windows 8 4. some Windows Server versions? For each system the variants would be: 1. 32-bit system, 32-bit GHC 2. 64-bit system, 32-bit GHC 3. 64-bit system, 64-bit GHC Right now I have done the procedure above for my own 64-bit Windows 7/32-bit GHC pair. I also added some simple logic of choosing between "Simple" build and "Configure-type" build within Setup.hs. The result is a version of network package that can be built with or without MSYS on Windows and without change on other platforms. If you want to try it it is available from Github: https://github.com/tener/network . I have also created a pull request against haskell/network you can check out: https://github.com/haskell/network/pull/141 Please let me know if you think this is a reasonable approach. -- Krzysztof On Mon, Aug 4, 2014 at 6:21 PM, Michael Snoyman wrote:

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