Building network without MSYS [Was: Splitting Network.URI from the network package]

Mon Aug 4 20:52:51 UTC 2014

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 <michael at snoyman.com> wrote:

>
>
>
> 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.
>
> _______________________________________________
> 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/20140804/5f54603c/attachment.html>