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

Thu Feb 27 08:05:43 UTC 2014

i have no clue, i'm just there dealing with the fallout of a confused new
person who is convinced that cabal just doesn't work. and no fallout
shelters in sight so I have to provide quick solutions that work™ to
prevent frustration radiation poisoning.

why not just put all the modules in the same package?  :)
I jest, BUT i have a real point in saying that.

why should i have to use a wrapper package which pins all the constraints?

On Thu, Feb 27, 2014 at 12:58 AM, Michael Snoyman <michael at snoyman.com>wrote:

>
>
>
> 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/2a0bd036/attachment.html>