[Haskell-beginners] How to deal with library dependencies?

[Lorenzo Bolla]

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 at 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