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.