[Haskell-cafe] Best approach to avoid dependency hells

[Albert Y. C. Lai]

On 12-12-05 01:52 PM, Ivan Perez wrote:
> 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 understand the conflict. First you have GHC, and it comes with 
bytestring-0.9.2. Then one of two things happen, but I can't see a 
conflict either way:

* You request A, but A should be fine with the existing 
bytestring-0.9.2. Then you request B, but B should be fine with the 
existing A you have, and indifferent about bytestring.

OR

* You request B. So cabal-install bring in A and then B. A should be 
fine with the existing bytestring-0.9.2, and then B should be fine with 
that A and indifferent about bytestring.

If there is a conflict, it cannot be deduced from your data.

> I would like to the best approach to 1) avoid these situations and 2)
> fix them when they happen.

To prevent or foresee problems, add --dry-run to your "cabal install" 
commands to see what packages are to be brought in, and check that list. 
If the list contains packages you already have, same version or 
different version, then it is a potential problem. It is fine with the 
pros of cabal matters, they know how to live with it, and they tell 
others it's fine. But it is not fine for non-pros, it causes confusion.

I am fine with adding constraints such as "bytestring == the version 
that comes with GHC" to your "cabal install" commands and/or your 
~/.cabal/config, contrary to what someone else says. The problem with 
setting it in ~/.cabal/config is that you will forget to change it when 
you change to another GHC version. But adding it manually as 
--constraint flags to "cabal install" may help with specific cases. How 
do you know whether it helps or hurts one case? Use --dry-run to find 
out. Play with adding and omitting constraints to see which list you 
like most.

Your different projects can have different needs. This is why cabal-dev 
or other sandboxing methods are a good idea. This does not deny that 
some packages benefit all of your projects and can be installed outside 
sandboxes. You have to choose carefully.

To clean up a mess or bad state, see my
http://www.vex.net/~trebla/haskell/sicp.xhtml#remove
Actually, see the whole thing.
It does not suffice to erase ~/.cabal (and mostly unnecessary). It does 
not suffice to erase GHC and then install the same GHC version again. 
You are still missing an important piece of metadata.