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@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@snoyman.com> wrote:



On Thu, Feb 27, 2014 at 10:05 AM, Carter Schonwald <carter.schonwald@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@haskell.org
http://www.haskell.org/mailman/listinfo/libraries