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