Re: PVP proposal: no upper bounds on non-upgradeable packages

On Thu, Apr 10, 2014 at 4:33 AM, Adam Bergmark wrote:

I agree with Erik that non-upgradeable packages should be constrained to installed in Cabal. I have this in my cabal config as well. Better error messages for this would be gravy.

...

Upper bounds should not be included on non-upgradeable packages, such as base and template-haskell (are there others?). Removing these upper bounds throws away what I consider vital information: What version of GHC was this package successfully built against? As was discussed elsewhere, perhaps base and other core packages should have fewer breaking changes instead.

Are you aware that there's a tested-with field in cabal for exactly that purpose? I'm not sure why you'd prefer a proxy variable with side-effects to the real thing.

...

Alternatively, we should establish some accepted upper bound on these packages, e.g. many people place base < 5 on their code. I would be okay with this if we knew what would change up until base 5, but we don't so I think the effect would be the same as if the upper bound was dropped.

...

* Some build plans that would have previously been impossible are now possible, without resorting to the nuclear option of --allow-newers.

I've seen this argument about making more builds plans possible several times and I don't get it. Yes it's great if a package still works when one of its dependencies goes through a breaking change, but the point is that the maintainer (generally) does not know this until that version is released. An upper bound gives the maintainer some time to test the new version, if it's just a matter of bumping the upper bound then this can be done really fast, if bigger changes need to be done then the lack of an upper bound wouldn't have helped since the package was broken with that version anyway. If we restrict this to the non-upgradeable packages, maintainers have time to test on a new version of GHC before the next haskell-platform release, as is the case right now.

I don't understand what you're saying here. How do maintainers get extra time by having an upper bound on base? Either way, beta testers of GHC will be sending reports to please support the new GHC, this just makes it slightly easier for those beta testers to get useful reports to maintainers. Michael

You can probably tell that I'm -1 on this :)

On Thu, Apr 10, 2014 at 12:57 AM, Ganesh Sittampalam wrote:

...

-1 (because of the listed downsides)

On 09/04/2014 20:24, Michael Snoyman 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.

[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

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

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