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

[Carter Schonwald]

ah, pardon the implication (one challenge when helping people new to
haskell is i don't often get the console logs that were part of their
"cabal ").

So we have a mix of concerns, some of which are a historical  artifact of
cabal having been terrible in the past, and now its not (quite) as bad, but
far from perfect.

things I think would help on all fronts, and I think we (as a community)
actually need to figure out how to allocate manpower to the following

a) improve the solver tooling. Get some sort of SMT solver ACTUALLY in
cabal.

The constraint plans aren't that complicated compared with SMT solver
benchmarks!
 I know of several folks who've done their own internal hacked up cabal to
do this, and i've heard rumors that *someone* (don't know )

b) proactively work on tooling to improve how constraint failures are
reported (though perhaps having the SMT solver tooling would address this).

It'd be very very helpful to be able to identify the *minimal* set of
constraints + deps that create a conflict, and explanations in that error
the exhibit how the conflict in constraints is created.

I think everyone agrees these are valuable, its just it requires someone to
be able to commit the time to actually doing it. (which is the tricky bit)



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

>
>
>
> On Thu, Feb 27, 2014 at 10:05 AM, Carter Schonwald <
> carter.schonwald at gmail.com> wrote:
>
>> 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?
>>
>>
> That's a great question. It seems to be the question no one's able to
> answer, myself included. As I keep saying, Yesod went through years of PVP
> compliance, and users were constantly having build problems. It may have
> been the cabal-install dependency solver prior to 0.14, and now that
> problem is resolved. I'm not sure. I know that the new dependency solver
> used Yesod as a stress test case.
>
> Releasing yesod-platform was pragmatic on two fronts:
>
> 1. It guaranteed a sane build plan when cabal (for whatever reason)
> couldn't determine one.
> 2. It prevents users from getting a completely untested set of packages,
> hopefully insulating them from some of the turbulence of Hackage.
>
> I think you need to dial back your assumptions here. Your initial email
> made it sound like I'd broken the Yesod stack single-handedly a bunch of
> times recently. That worries me. If that actually happened, please explain
> how it happened. If users are getting build errors when they don't use
> yesod-platform, well, that's something we've known about in the Yesod
> community for a long time. The PVP didn't solve it, yesod-platform is a
> hack which fixes most of the end-user issue, and I'd love to get to a real
> solution.
>
> Michael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140227/2422f3b2/attachment-0001.html>