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

[Greg Weber]

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> 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>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(tm) 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
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140227/6d68b2c9/attachment-0001.html>