[Haskell-cafe] Cabal message problem.

[Duncan Coutts]

On 16 December 2010 13:38, Daniel Fischer
<daniel.is.fischer at googlemail.com> wrote:

> The problem is that without upper bounds, things will break a lot when
> packages undergo API changes, but probably more often things will also work
> with the new API. So with upper bounds, you prevent breakage at the cost of
> preventing builds which would work.

It's a tradeoff.

One way to look at it is to say that upper bounds are just bad because
there's a chance it might work if you were not using the bit of the
API that changed.

The other is to look at it from the point of users of the package and
what kind of error messages they get. If there's no upper bound they
get a random compile failure and they don't know what is wrong, who is
to blame or how to fix it. If there is an upper bound then we at least
have the chance to tell the users that the package does not work (or
at least has not been tested by anyone) with that version of a
dependency. We also have the possibility of picking different deps
that are known to work. Yes, this stuff depends on having a reasonably
clever dependency resolution algorithm, but I think we can improve in
that area, there's plenty of ideas floating about, but less time to
implement them.

> Maybe a flag "ignore upper bounds and try with the latest" for cabal would
> be a solution. Would that be hard to implement or easy?

That suggestion has come up quite a few times. I think it's probably a
good idea.

Duncan