On Wed, Aug 13, 2014 at 12:28 PM, Johan Tibell
I asked Duncan for some feedback, so here's a summary for his benefit:
First Michael's (and our) problem statement:
- 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.
The two options:
*Option 1: Users of Network.URI use a flag*
- network-2.6 no longer exposes Network.URI. - network-uri-2.6 exposes Network.URI.
User who want only network-uri writes:
flag network-uri description: Get Network.URI from the network-uri package default: True
library if flag(network-uri) build-depends: network-uri >= 2.6 else build-depends: network < 2.6
(If the user also wants network he/she adds it to the first build-depends line.)
Cons:
- More typing (an extra flag declaration, an if statement, and an extra build-depends line). - Could trigger possible unknown solver bugs (but there are no confirmed such bugs).
I'd add in a very big "users will very likely not know the right way to put in the build-depends correctly." This contrasts with your second con under option 2. I think it's highly unlikely that users will think that using a flag to indicate a conditional dependency is the obvious solution. Instead, I'd imagine we'd end up in the situation where users put in a dependency on both network and network-uri, it works on their systems, and then we get lots of downstream breakage when someone with an older version of network tries to build the package.
*Options 2: Users of Network.URI depend on both network and a specially crafted network-uri*
- network-2.5 exposes Network.URI. - network-2.6 no longer exposes Network.URI. - network-uri-2.5 Exposes no modules. Depends on < network-2.6. - network-uri-2.6 exposes Network.URI. Depends on network >= 2.6.
User who want network-uri (only) writes:
build-depends: network >= 2.5 && < 2.7, network-uri >= 2.5 && < 2.7
Cons:
- network-uri has a false dependency on network (i.e. it doesn't actually need that package). - You can't build against a new version of text *and* use the network-uri package (this is the current problem we have with network in the problem description).
Can you clarify this point? I would imagine that network will no longer
have *any* dependency on text, so I don't see where this comes from.
- We need to teach users about the above special build-depends construction, just for use with the network and network-uri packages. Users who don't know of this special construction will still use a flag (and thus get a mix of cons from both approaches.)
I think this is a bigger con with option 1. Teaching users about a strange
flag conditional is far more difficult IMO than saying "just depend on both network and network-uri." Yes, both approaches have the potential create downstream breakage, but I think this one is easier to educate about.
- network-uri-2.5 is an empty package, which might lead to slight confusion for some users.
I'd consider that a *very* minor point. network-uri-2.5 would simply have a note in its description field explaining why it exists, likely with a link to this thread. Michael