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

[Carter Schonwald]

I don't care. I want a better solver.  And I'm willing to help make it
happen.

On Thursday, February 27, 2014, Greg Weber <greg at gregweber.info> wrote:

> I actually think work on the a) cabal solver has been a distraction from
> more pressing issues: the need for sandboxes (that is done now) and
> reproducible builds (frozen dependencies). If you look at Ruby's Bundler,
> which has been extremely successful, it has historically (maybe they have a
> better solver now) been a dumb tool in terms of its solver that works
> extremely well. I think 90+% of this conversation is pretty wasteful,
> because once we have reproducible builds everything is going to change. If
> the energy could be re-directed to being able to create reproducible builds
> in Haskell, then we could figure out what the next most important priority
> is.
>
> Of course, I agree that better error messages like b) are always valuable.
>
> yesod-platform is essentially a reproducible build and it has been able to
> fix dependency issues that previously seemed unfixable.
> At my work we add a cabal.config to our projects to create reproducible
> builds, and everyone in industry does something similar for their
> applications.
>
>
> On Thu, Feb 27, 2014 at 12:49 AM, Carter Schonwald <
> carter.schonwald at gmail.com<javascript:_e(%7B%7D,'cvml','carter.schonwald at gmail.com');>
> > wrote:
>
>> 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<javascript:_e(%7B%7D,'cvml','michael at snoyman.com');>
>> > wrote:
>>
>>>
>>>
>>>
>>> On Thu, Feb 27, 2014 at 10:05 AM, Carter Schonwald <
>>> carter.schonwald at gmail.com<javascript:_e(%7B%7D,'cvml','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
>>>
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org<javascript:_e(%7B%7D,'cvml','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/829c8052/attachment.html>