I haven't tested this with the new cabal-install solver, but with the old
one the user would get much worse error messages if 'template-haskell' had
bounds - cabal-install would start trying to install the old version and
fail, sending the user off on a wild goose chase trying to figure out how
to make that install work.
If you have no bounds then the error is much easier to diagnose - the
library needs to be modified to work with the version of template-haskell
currently installed.
I'm +1 on this policy, even though I would prefer the fix be in
cabal-install itself.
On Wed, Apr 9, 2014 at 3:24 PM, Michael Snoyman
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.
[1] http://www.haskell.org/pipermail/libraries/2014-April/022529.html [2] http://www.yesodweb.com/blog/2014/04/proposal-changes-pvp
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries