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

[Austin Seipp]

Hi Greg,

On Thu, Feb 27, 2014 at 10:30 AM, 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.

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/