qualified imports, PVP and so on (Was: add new Data.Bits.Bits(bitZero) method)

[Edward Kmett]

This is currently disabled if you go to try it.


On Tue, Feb 25, 2014 at 11:38 AM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> This thread is kinda missing an important point.
>
> Namely that on hackage now, the admins and trustees have the power to edit
> the cabal files to fix broken constraints. (As do maintainers of their own
> packages)
>
> Whether relaxing incorrectly conservative or over strengthening overly lax
> constraints, this now doesn't require a rerelease to "fix".  There are
> valid reasons of provinence for why that might not make sense in all case
>
> Unless I'm missing the point, doesn't that solve most of the matter?
> -carter
>
>
> On Tuesday, February 25, 2014, Michael Snoyman <michael at snoyman.com>
> wrote:
>
>>
>>
>>
>> On Tue, Feb 25, 2014 at 5:12 PM, Brandon Allbery <allbery.b at gmail.com>wrote:
>>
>>> On Tue, Feb 25, 2014 at 1:44 AM, Michael Snoyman <michael at snoyman.com>wrote:
>>>
>>>> But that's only one half of the "package interoperability" issue. I
>>>> face this first hand on a daily basis with my Stackage maintenance. I spend
>>>> far more time reporting issues of restrictive upper bounds than I do with
>>>> broken builds from upstream changes. So I look at this as purely a game of
>>>> statistics: are you more likely to have code break because version 1.2 of
>>>> text changes the type of the map function and you didn't have an upper
>>>> bound, or because two dependencies of yours have *conflicting* versions
>>>> bounds on a package like aeson[2]? In my experience, the latter occurs far
>>>> more often than the former.
>>>
>>>
>>> I have a question for you.
>>>
>>> Is it better to save a developer some work, or is it better to force
>>> that work onto end users?
>>>
>>>  Because we keep constantly seeing examples where saving the developer
>>> some upper bounds PVP work forces users to deal with unexpected errors, but
>>> since Haskell developers don't see that user pain it is considered
>>> irrelevant/nonexistent and certainly not any justification for saving
>>> developers some work.
>>>
>>> Personally, I think any ecosystem which strongly prefers pushing
>>> versioning pain points onto end users instead of developers is doing itself
>>> a severe disservice.
>>>
>>> Are there things that could be improved about versioning policy?
>>> Absolutely. But pushing problems onto end users is not an improvement.
>>>
>>>
>> I think it's a false dichotomy. I've received plenty of complaints from
>> users about being unable to install newer versions of some dependency
>> because a library that Yesod depends on has an unnecessary strict upper
>> bound. Are there situations where the PVP saves a user some pain? Yes. Are
>> there situations where the PVP causes a user some pain? Yes.
>>
>> It's disingenuous to frame this as a black and white "developer vs user"
>> issue, it's far more complex than that. After a lot of experience, I
>> believe the PVP- or at least strict adherence to it- is a net loss.
>>
>> And I think the *real* solution is something like Stackage, where
>> curators have taken care of the versioning pain points instead of either
>> developers or end users. Linux distributions have been doing this for a
>> long time.
>>
>> Michael
>>
>
> _______________________________________________
> 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/20140225/abd409a8/attachment.html>