[Haskell-cafe] Cabal dependency hell

[Jason Dagit]

On Sun, Apr 11, 2010 at 9:26 AM, Duncan Coutts <duncan.coutts at googlemail.com
> wrote:

> On Mon, 2010-03-08 at 13:33 +0000, Maciej Piechotka wrote:
> > While I love Haskell it's packaging system have some problems -
> > especially with parsec.
> >
> > Currently I'm not able to install an practically anything using cabal
> > due to version mismatches (or at least packages linking to both version
> > of parsec).
> >
> > I found the following problems in various cabal packages (the examples
> > are only examples - please do not be offended):
> > - The constraints are too loose. It is written that package works with
> > '>0.6 && <1' but in 0.8 the API has been changed (example of tagsoup &
> > hxt. Fixed hxt versions depends on ghc 6.12... and ghc 6.10 if you
> > change 2 lines in cabal file)
> > - The constraints are too tight. It is written that package works with
> > 'parsec <3' but it can run with 3.0 and 3.1 (a lot of packages)
>
> Here are a few things which I would like to see implemented that would
> help all this:
>
>      * Build reporting in the hackage server
>        The idea here is that cabal sends back anonymous reports to the
>        server to say if a package compiled or not, and against what
>        versions of dependencies. This would make it clearer to
>        maintainers if their dependency versions are correct.
>        Additionally I think it would be useful for hackage to provide
>        tweaked .cabal files for packages with updated constraints, even
>        without new version uploads.
>        We are proposing a GSoC project which would cover some of this.
>
>      * A package API tool and greater use of the PVP
>        We do have a package versioning policy that maintainers can
>        choose to follow. This helps users of the package write more
>        accurate dependency version constraints. What we lack is a tool
>        to help maintainers check that they are correctly following the
>        PVP.
>        We also have a GSoC proposal for a package tool.
>
>      * Private "build-depends"
>        This would help the parsec 2 vs parsec 3 issue. Most packages
>        that depend on parsec, or QuickCheck, do not export (as part of
>        their public API) functions that use types from the parsec/QC
>        packages. That is, the use of those packages is entirely
>        encapsulated and invisible to clients. In this case, diamond
>        dependency problems are impossible and it would be ok to use
>        different versions of the same package within the same
>        dependency graph. Currently cabal does not know which
>        build-depends are public and which are private. The extension
>        would be to let package authors mark some depends as private
>        (though this would also need to be checked).
>
>      * Improved dependency resolution algorithm in cabal-install
>        The constraint solver is currently not very smart. It does not
>        do so well with tight version constraints, which is exactly what
>        we will get more of, as people use the PVP more. The resolver
>        could be improved to do significantly better in these
>        situations. I have an algorithm in my head, but not much time to
>        implement it.
>

I've noticed another type of diamond dependency problem.  Suppose I build
and install Foo today and it depends on Bar 2.0.0.  In a week, I install Bar
2.0.1.  Next I installed Baz that also depends on Bar, and it gets Bar
2.0.1.  When I install a package that depends on Foo, Baz, and possibly Bar,
then cabal won't be able to figure out proper dependencies because Foo needs
one version of Bar and Baz needs a different version.  But if all these
packages followed the PVP, then either version of Bar could have been used,
if it was used consistently.

i'm not sure what is the best solution to this problem.  Perhaps in this
scenario, cabal should ask the user if it should rebuild Foo and/or Baz so
they use the same Bar.  I think this could lead to a lot of rebuilding, and
that rebuilding gets tedious when you're doing it manually.

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100411/8d9bbdb3/attachment.html