Hi all, I've recently installed the latest yesod-platform with cabal and now I'd like to install yesod-markdown, too. Problem is, yesod-markdown refuses to install because it depends on libraries older than the ones installed by yesod-platform on my system: for example, yesod-markdown requires 0.4 <= blaze-html < 0.5, but latest yesod-platform depends on blaze-html 0.5.0. This problem is obviously more general, and so is my question: How to handle packages that depend of different versions of the same library? Would you just install the "highest common version" across all the packages that depend on it? What if it doesn't exist? 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? To me, it looks like dependencies in .cabal files are usually too strict. 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. Is this rule of minor/major version numbers followed/agreed upon in Haskell libraries? Thanks, L. -- Lorenzo Bolla http://lbolla.info
I believe there is a post on this from the Yesod developers:
http://www.yesodweb.com/blog/2012/04/cabal-meta
It looks like the suggest using a better wrapper around cabal and making
virtual play-spaces to install into. I confess, I haven't taken the time to
learn it, but it sounds like they have thought through this a couple times.
Good luck!
Tim
On Thu, Apr 26, 2012 at 9:42 AM, Lorenzo Bolla
Hi all,
I've recently installed the latest yesod-platform with cabal and now I'd like to install yesod-markdown, too.
Problem is, yesod-markdown refuses to install because it depends on libraries older than the ones installed by yesod-platform on my system: for example, yesod-markdown requires 0.4 <= blaze-html < 0.5, but latest yesod-platform depends on blaze-html 0.5.0.
This problem is obviously more general, and so is my question: How to handle packages that depend of different versions of the same library?
Would you just install the "highest common version" across all the packages that depend on it? What if it doesn't exist? 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?
To me, it looks like dependencies in .cabal files are usually too strict. 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. Is this rule of minor/major version numbers followed/agreed upon in Haskell libraries?
Thanks, L.
-- Lorenzo Bolla http://lbolla.info
_______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners
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
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
participants (3)
-
Brent Yorgey -
Lorenzo Bolla -
Tim Perry