On Tue, Jun 7, 2016 at 9:31 AM, Ben Lippmeier <benl@ouroborus.net> wrote:

> On 7 Jun 2016, at 7:02 am, Dominick Samperi <djsamperi@gmail.com> wrote:
>
> Why would a package developer want to upper bound the version number
> for packages like base? For example, the clash package requires
>
> base >= 4.2 && base <= 4.3

I put an upper bound on all my libraries as a proxy for the GHC version. Each time a new GHC version is released sometimes my libraries work with it and sometimes not. I remember a “burning bridges” event in recent history, when the definition of the Monad class changed and broke a lot of things.

Suppose you maintain a library that is used by a lot of first year uni students (like gloss). Suppose the next GHC version comes around and your library hasn’t been updated yet because you’re waiting on some dependencies to get fixed before you can release your own. Do you want your students to get a “cannot install on this version” error, or some confusing build error which they don’t understand?

This is a popular but ultimately silly argument. First, cabal dependency solver error messages are terrible; there's no way a new user would figure out from a bunch of solver output about things like "base-4.7.0.2" and "Dependency tree exhaustively searched" that the solution is to build with an older version of GHC. A configuration error and a build error will both send the same message: "something is broken". Second, this argument ignores the much more likely case that the package would have just worked with the new GHC, but the upper bound results in an unnecessary (and again, terrible) error message and a bad user experience. The best case is that the user somehow learns about --allow-newer=base, but cabal's error message doesn't even suggest trying this and it's still an unnecessary hoop to jump through.

Experienced users are also only harmed by these upper bounds, since it's generally obvious when a program fails to build due to a change in base and the normal reaction to a version error with base is just to retry with --allow-newer=base anyways.

Of course the best thing is to stick to the part of the language that is unlikely to be broken by future versions of base; sadly this seems to be impossible in the current climate...

Regards,

Reid Barton