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

[Michael Snoyman]

On Wed, Feb 26, 2014 at 6:35 PM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> 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.
>
>
If you have the details on when that happened, I'd be very curious to hear
them. I thought my release process had ironed out those possibilities, but
if not, I'd like to know about it. Which packages conflicted?


> 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".
>
>
Are these people usually following the actual Yesod installation
instructions? Does anyone tell them to follow the Yesod installation
instructions? I created the yesod-platform because the PVP *wasn't* fixing
this issue. That's why I'm so skeptical that "start using the PVP" would
actually fix any of that.


> 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/20140227/0c4e77f3/attachment-0001.html>