Hi Greg,
On Thu, Feb 27, 2014 at 10:30 AM, 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.
I'd like to carefully point out however, that it is not a zero-sum game - work dedicated to improving the constraint solver is not work which is implicitly taken away any other set of tools - like a 'freeze' command. There is no 'distraction' IMO - it is a set of individuals (or companies, even) each with their own priorities. I think this is the sign of a healthy community, actually - one that places importance on its tools and seeks to find optimal ways to improve them in a variety of ways. A freeze command and an improved solver are both excellent (and worthy) improvements. In reality, bundler works precisely for the reason you said it did: it avoids all the actually difficult problems. But that comes at a cost, because Bundler for example can't actually tell me when things *are* going to break. If I bump my dependencies, create a new Gemfile lock, and test - it could all simply explode later on at runtime, even if it could have been concluded from the constraints that it was all invalid in the first place. The only thing bundler buys me is that this explosion won't potentially extend to the rest of my global environment when it happens. Which is a good thing, truth be told, and why it is so popular - otherwise this happens constantly. Despite the fact people complain when cabal bails about reinstalls breaking things - this is infinitely preferable to things 'working now' and 'exploding later'. Even in a sandbox, or when you unfreeze your dependencies to upgrade them. Work on improving the solver here is not wasted IMO - and even the bundler developers are looking into things like SAT solvers amongst many options, precisely because the basic resolver has many bugs. Even if it's all safe in a sandbox: https://github.com/bundler/bundler/issues/2437 These two concerns are, as far as I can see, in no way opposed in spirit or practice, and suggesting one is essentially wasted effort that distracts people - when I see no evidence of that - strikes me as odd.
Of course, I agree that better error messages like b) are always valuable.
I think that the only way to do that is to actually stress the solver and integrate build reports into things like the Hackage server. Going by heresay from users for these issues is, in my experience, tremendously difficult. Freezing every dependency to its exact necessary state so it always works does not necessarily tell us anything about this behavior in the large (besides "it does work"), how the solver fails, how to report that in a sensible manner, or what kind of problems or usage patterns which will arise in conjunction with these things. 'cabal install' might as well be Prolog and tell me 'Yes' or 'No' if things will work, if we're not interested in that stuff. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/