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

On Wednesday, February 26, 2014, Brandon Allbery wrote:

On Wed, Feb 26, 2014 at 2:11 AM, Michael Snoyman javascript:_e(%7B%7D,'cvml','michael@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@gmail.com javascript:_e(%7B%7D,'cvml','allbery.b@gmail.com'); ballbery@sinenomine.netjavascript:_e(%7B%7D,'cvml','ballbery@sinenomine.net'); unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net