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.