[Haskell-cafe] Cabal dependency hell
duncan.coutts at googlemail.com
Sun Apr 11 12:26:52 EDT 2010
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
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
Volunteers welcome on all tasks.
More information about the Haskell-Cafe