[Haskell-cafe] Best approach to avoid dependency hells

Jason Dagit dagitj at gmail.com
Wed Dec 5 20:13:01 CET 2012


On Wed, Dec 5, 2012 at 10:52 AM, Ivan Perez <ivanperezdominguez at gmail.com>wrote:

> Hello everyone,
>
> I've spent the last couple of days fighting my way around a dependency
> hell with my own libraries and packages.
>
> If I install them package by package (by hand), I'm very likely to hit
> one of these conflicts that I'm talking about. A simple example of
> something that did happen:
> - Package A depends on bytestring, and is compatible with both 0.9.* and
> 0.10.*
> - Package B depends on ghc, which I installed using the package
> manager and which depends on bytestring 0.9.2
> - Package B depends on package A.
>
> I do not want to add to the cabal files that B depends on bytestring
> 0.9.*, because it's not true, or that A depends on bytstring 0.9,
> because it's also not true.
>
> I would like to the best approach to 1) avoid these situations and 2)
> fix them when they happen.
>
> Regarding (2), Is there any way to automatically rebuild all the
> broken packages?
> Regarding (1), I thought about using cabal-dev, but I think I'll just
> have the same problem, won't I? After all, I started from a clean
> fresh ghc installation and I just installed what I needed to make my
> program run.
>

Let's say you are working in a directory foo that contains a cabal file for
package foo. When you type 'cabal-dev install', cabal-dev looks at
foo.cabal in the current directory, it uses it to calculate constraints and
then installs the dependencies locally that satisfy those constraints. It
also has an install-deps command if you just want to install the deps but
not build/install foo. Additionally, if you want to use locally modified
versions of the dependencies use 'cabal add-source <path to dep>' from the
foo directory to add your locally modified package to foo's index so that
subsequent cabal-dev operations can find it and install it.

Basically, don't install the deps by hand. Let cabal-dev figure out the
mutually compatible versions and install that *locally* to where you're
building foo.

As for the problem of recursively rebuilding the deps, I think 'cab' [1]
solves this but I haven't tried it.

[1] http://hackage.haskell.org/package/cab



> I also thought about adding process, bytestring and other global
> packages to the list of constraints in ~/.cabal/config. Would this be
> a good approach, or will it lead to bigger headaches in the future
> (for instance, in the form of programs that just cannot be installed
> at all)?
>

Adding these constraints will come back to bite you. That's been my
experience.


>
> Also, is there any way to detect potential dependency hells without
> having to install a package? (Some tool that will analyse the
> dependency information (statically) and determine more strict or
> incorrect upper and lower bounds for the dependencies of a package.)
>

--dry-run?

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20121205/c5910df3/attachment.htm>


More information about the Haskell-Cafe mailing list