For this particular issue, in general I'm +1.

The main quibble I have with it the base bound was needed for the 'default to base 3 if no bound is specified' hack, though. The base < 5 convention is a by-blow of that era.

As for the others, bounds in third party packages on template-haskell cause an unreasonably large fraction of the user complaints I receive. An even worse situation is where they _do_ wind up "upgrading" template-haskell and now it doesn't work at all, silently several packages later.

That said, this should be rather mitigated going forward by:

https://github.com/hvr/cabal/commit/65e9b88bc849e76040ed7947591ea7172cd02db5

which closes out 

https://github.com/haskell/cabal/issues/1444

and

https://github.com/haskell/cabal/issues/667

So in essence, it _is_ being fixed in cabal.

-Edward


On Wed, Apr 9, 2014 at 3:24 PM, Michael Snoyman <michael@snoyman.com> wrote:
At Herbert's request, I'm splitting off this part of the PVP proposal I made[1] to its own separate proposal. Same discussion period of three weeks. The proposal is:

Upper bounds should not be included on non-upgradeable packages, such as base and template-haskell (are there others?). Alternatively, we should establish some accepted upper bound on these packages, e.g. many people place base < 5 on their code.

The purpose (elaborated in my blog post[2]) is that these upper bounds virtually never provide for a successful build. Instead, they are purely about what error messages the user receives. With this change:

* Some build plans that would have previously been impossible are now possible, without resorting to the nuclear option of --allow-newers.
* Instead of cabal version bound error messages, users get GHC compiler errors that can be fed back upstream to help get packages fixed more expediently.

Downsides I'm aware of:

* If you consider the cabal error messages more user friendly, then the error message quality goes down.
* Users may find out later than they do right now about a failing build.

[2] http://www.yesodweb.com/blog/2014/04/proposal-changes-pvp

_______________________________________________
Libraries mailing list
Libraries@haskell.org
http://www.haskell.org/mailman/listinfo/libraries