[Haskell-cafe] Cabal dependency hell

[Duncan Coutts]

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.

Volunteers welcome on all tasks.

Duncan