On Thu, Apr 26, 2012 at 01:37:26PM -0400, Brent Yorgey wrote:
On Thu, Apr 26, 2012 at 05:42:37PM +0100, Lorenzo Bolla wrote:
Hi all,
This problem is obviously more general, and so is my question: How to handle packages that depend of different versions of the same library?
There's no really good answer to this question (yet).
Would you manually patch the cabal files for all the packages in the dependency tree, hoping that newest libraries are backward compatible? Would you wait for the library developers to update their cabal file every time a library they rely upon changes?
One of these two is what I would usually do. Which one I would choose depends on how badly I want the package in question and how comfortable I am trying to manually patch the cabal file.
To me, it looks like dependencies in .cabal files are usually too strict.
That's one way of looking at it; the alternative, however, would be that dependencies are too lax, and then things might install just fine but not work; or maybe you'd get crazy type errors instead of version errors. Which would you rather have? Personally, I'd rather have version errors, and let the package maintainers figure out the type errors when they update their packages.
Or, packages should agree on the meaning of "minor" version numbers. For example, if blaze-html's API did not change from 0.4 to 0.5 (supposing that API changes are identified by a change in the major version number), then there is no point in the libraries that depend on it to require a dependency <0.5.
Most packages do agree on this; in particular they conform to the Package Version Policy:
http://www.haskell.org/haskellwiki/Package_versioning_policy
Among other things it says that breaking API changes are identified by changes in the first and/or second component of the version number.
The problem is that even if the API of a package changes (thus necessitating a bump in at least the second component of the version number), packages that depend on it may continue to work with both the old and new versions, if they didn't happen to use the part of the API that changed.
-Brent
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners
Thanks for your suggestions. I gave cabal-meta a try, but it failed (actually, cabal failed) to install packages directly from github because it can't handle https protocol, apparently. So, I did it by hand: git clone && cd && cabal install Only in 1 case I had to update the cabal file for the package from github (and I already submitted a pull request for that patch), meaning that github is more up-to-date than hackage, usually. Unfortunately, though, not all the packages I git-cloned are installed simply with "cabal install" (one required "make"): but I consider those packages broken. In fact, why not having a tool that relies exclusively on github? That is, it downloads some metadata for a package from hackage (the source repo) and then goes out, fetches the source, and builds it locally. Is there already a tool like this? Thanks, L. -- Lorenzo Bolla http://lbolla.info