[Haskell-cafe] How to determine correct dependency versions for a library?

Tobias Müller troplin at bluewin.ch
Wed Nov 14 20:20:53 CET 2012

Peter Simons <simons at cryp.to> wrote:
> Hi Clark.
>  > I think we just use dependencies [to specify] different things.
> If dependency version constraints are specified as a white-list --
> i.e. we include only those few versions that have been actually
> verified and exclude everything else --, then we take the risk of
> excluding *too much*. There will be versions of the dependencies that
> would work just fine with our package, but the Cabal file prevents
> them from being used in the build.
> The opposite approach is to specify constraints as a black-list. This
> means that we don't constrain our build inputs at all, unless we know
> for a fact that some specific versions cannot be used to build our
> package. In that case, we'll exclude exactly those versions, but
> nothing else. In this approach, we risk excluding *too little*. There
> will probably be versions of our dependencies that cannot be used to
> build our package, but the Cabal file doesn't exclude them from being
> used.
> Now, the black-list approach has a significant advantage. In current
> versions of "cabal-install", it is possible for users to extend an
> incomplete black-list by adding appropriate "--constraint" flags on
> the command-line of the build. It is impossible, however, to extend an
> incomplete white-list that way.
> In other words: build failures can be easily avoided if some package
> specifies constraints that are too loose. Build failures caused by
> version constraints that are too strict, however, can be fixed only by
> editing the Cabal file.
> For this reason, dependency constraints in Cabal should rather be
> underspecified than overspecified.

The blacklisting approach has one major disadvantage that noone has
mentioned yet:
Adding more restrictive constraints does not work, the broken package will
be on hackage forever, while adding a new version with relaxed constraints
works well.

Consider the following example:

A build-depends: B ==2.5.* C ==3.7.* (overspecified)
B build-depends: C ==3.* (underspecified)

Everything works nice until C- appears with incompatible changes
that break B, but not A. 

Now both A and B have to update their dependencies and we have now:

A build-depends: B ==2.5.* C >=3.7 && <3.9
B build-depends: C >=3 && <3.8

And now the following combination is still valid:
B (old version)


PS: This is my first post on this list. I'm not actively using haskell, but
following this list for quite a while just out of interest.

More information about the Haskell-Cafe mailing list