PVP proposal: no upper bounds on non-upgradeable packages

[Michael Snoyman]

On Thu, Apr 10, 2014 at 4:33 AM, Adam Bergmark <adam at bergmark.nl> 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 <ganesh at earth.li>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 at haskell.org
>> > http://www.haskell.org/mailman/listinfo/libraries
>> >
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140410/7f02149a/attachment-0001.html>