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