On Wed, Aug 13, 2014 at 12:28 PM, Johan Tibell <johan.tibell@gmail.com> wrote:
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