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.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
