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