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

[Carter Schonwald]

michael,
respectfully, i've had the experience of trying to build a yesod app
(git-annex) in a cabal sandbox and i had a version conflict between your
own libraries. the only way I could build git-annex was by disabling the
web-gui yesod piece. The key piece here is your libraries conflicted with
themselves. Thats on you.

likewise, 9 time out of 10, when someone tries haskell for the first and
they tell me "cabal didn't work", I can guess "you tried to install yesod".
They then say "yes", and then I have to explain to them that "yesod has
notoriously fragile build constraints, even people who use yesod find it
maddening depending on their use case".

Michael, respectfully, most version constraint build failures are human
friendly, yours are cthulian.


I spend a wee bit of time  every major GHC release helping patch all the
various libs i use (including helping get pandoc ready for each new ghc).
It usaually pretty easy. Its often just needing a teeny bit of CPP for an
API change plus adjusting cabal range to be wider. I'm totally ok with
doing that 1-2 times a year in exchange for nice things. I'd rather do a
test and patch cycle every year than have surprise build failures.



On Wed, Feb 26, 2014 at 11:06 AM, Michael Snoyman <michael at snoyman.com>wrote:

>
>
> 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>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
>> ballbery at sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad
>> http://sinenomine.net
>>
>
> _______________________________________________
> 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/20140226/4f9713cb/attachment.html>