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

[Michael Snoyman]

On Wednesday, February 26, 2014, Brandon Allbery <allbery.b at gmail.com>
wrote:

> On Wed, Feb 26, 2014 at 2:11 AM, Michael Snoyman <michael at snoyman.com<javascript:_e(%7B%7D,'cvml','michael at snoyman.com');>
> > wrote:
>
>> I disagree with that assertion. I get plenty of complaints from users
>> about trying to install packages and getting "confusing error messages"
>> about cabal plan mismatches. I don't disagree that the PVP does make the
>> user experience better in some cases. What I disagree with is the
>> implication that it makes the user experience better in *all* cases. This
>> is simply not a black-and-white issue.
>>
>
> And how much of this is because you use your own versioning riules instead
> of what everyone else uses, thereby almost guaranteeing conflicts with
> everyone else when anything is updated? Seriously, the easiest way to get
> in trouble with the current system is to insist you get to not follow it,
> because stuff breaks. Asserting it's everyone else's fault isn't a solution.
>
>
Given that yesod followed the pvp strictly for a number of years and still
faced a large number of dependency issues, I don't think the problem is in
the lack of pvp support.

The most recent example of this issue was a user trying to use ghc 7.8 and
getting an error message about an upper bound on base in the esqueleto
package. I'm sure most of us on this mailing list would consider this an
easy error message, but at least one of our mythical end users was
seriously confused by this situation. It turned out that simply dropping
the upper bound was sufficient.

So I come back to this being a numbers game. End users don't necessarily
find cabal version error messages any better than ghc build failures. The
question is how can we minimize any kind of build failure.

Michael

Seriously, if everyone follows your versioning system, hsenv becomes
> essential just as RVM is essential in the Rails community; everyone has to
> provide their own curated system (your Stackage isn't going to serve
> everyone's needs, and asking you to make it serve everyone's needs is
> unreasonable and quite likely an impossible task when everyone else is also
> doing their own thing) and users have to maintain separate ecosystems for
> everything they use. This isn't maintainable for much of anyone.
>
>
Actually, why wouldn't stackage as a curated system work for everyone?
Stackage already has over 10% of hackage covered, and I'd imagine if you
look at hackage download numbers, that covers the vast majority of the most
downloaded packages. I really do think that a curated system could make
most people happy, if it gets enough buy-in.


> (I see someone else later on actually advocated this as a solution. It's
> not. It's an ongoing maintenance disaster that leads to unmanageable
> systems.)
>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allbery.b at gmail.com <javascript:_e(%7B%7D,'cvml','allbery.b at gmail.com');>
> ballbery at sinenomine.net<javascript:_e(%7B%7D,'cvml','ballbery at sinenomine.net');>
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140226/db24248e/attachment-0001.html>