PVP proposal: no upper bounds on non-upgradeable packages

[Erik Hesselink]

The only constraint that actually makes sense for template-haskell is
'installed', which I have in my cabal.config. I think this should
perhaps be built into cabal. This can then be combined with a
constraint on the known versions of TH a package works with.

Erik

On Wed, Apr 9, 2014 at 9:52 PM, Antoine Latter <aslatter at gmail.com> wrote:
> 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 <michael at 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.
>>
>> [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
>