That's a nice feature, big +1 from me. But it's not something we can rely
on until 7.10 has completely supplanted previous versions of GHC, but once
that happens, I'll look forward to using it for these situations.
Without module reexports, I'm fairly certain the breakage from something
like network-without-uri would be steeper than the proposal I'm making.
On Fri, Aug 8, 2014 at 3:11 PM, Edward Z. Yang
Hello Michael,
I'd like to chime in that with module reexports (a new feature landing in GHC 7.10, see https://ghc.haskell.org/trac/ghc/wiki/ModuleReexports), network-uri can safely reexport the Network.URI module defined in old versions of network (if both packages are included, GHC won't consider the import ambiguous.)
If you wanted to do things completely without breaking BC, this would suggest making a new package network-without-uri (but obviously a better name), and users who don't use Network.URI can switch their build-depends against that. network also defines Network.URI, but now it reexports modules from network-without-uri.
Cheers, Edward
This was brought up last year[1], and I'd like to bring it up again,
on a recent issue I was working through with a user[2]. I realize that
is a breaking change, but:
1. It's a minor breaking change: you simply need to add an extra package to your build-depends. 2. The problems caused by having a parsec dependency in network can be severe, especially for new users (I'll describe the details after the proposal).
Concretely, I believe we should do the following:
1. Create a new package, network-uri, version 2.5.0.0, which exposes no modules and has an upper bound `network < 2.6. 2. Create a second release of network-uri, version 3.0.0.0, which
Excerpts from Michael Snoyman's message of 2014-08-01 12:31:13 +0100: based this provides
the Network.URI module verbatim as provided by the network package today, and has a lower bound `network >= 3.0`. 3. Release network version 3.0.0.0, with no changes from the currently released version, except that (a) no Network.URI module is provided, and (b) there is no parsec dependency.
I don't remember how the discussion went last time, but I seem to remember general consensus. I'd like to set a discussion period of two weeks (August 15).
## Motivation
To give a concrete example of why this problem is severe, consider the following data:
* 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.
[1] http://www.haskell.org/pipermail/libraries/2013-January/019234.html [2] https://groups.google.com/d/msg/yesodweb/auk2vByXgO8/lUZ9oanKyMwJ