On Wed, Dec 5, 2012 at 10:52 AM, Ivan Perez
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