What's the reason behind cabal (dependency) hell?

9
votes

How does dependency hell happen in Cabal-install?

I read the following at Cabal/Survival - HaskellWiki:

1. What is the difficulty caused by Cabal-install?

The main difficulty with Cabal is otherwise known as 'dependency hell', in which the cabal-install does not manage to install a desired package for a reason or another, leading to large amount of manual work. As an example of this difficulty, consider a case where the user wishes to install packages A and B. Both of these work with package C, but not with the same version of C.

I understand why this would make sense generally, but not with Cabal-install/ghc-pkg, because you can have multiple versions of the same package installed.
It's as if every version is an entirely different package, with how that in many respects the version becomes a part of the package name (e.g. mustaches-0.1.0.0) -- and maybe it really is for ghc-pkg (I'm not entirely familiar with it, but it would make sense).

3
haskellcabal
\grumble{I can't help feeling cabal is just too slow, error prone, clunky and annoying. We're Haskell! There has to be a better way! Surely we could go with something more like nix (which is purely functional) but as portable as the Haskell platform. Even better, something where I can click "download" on hackage and it just happens, without clobbering anything. } – AndrewC

3 Answers

12
votes

You have scenarios like this:

enter image description here

Where both B and C depend on A. However, if they were installed at different times, they may depend on different versions of A. For example, A version 1 export type T = Int, but in version 2 it exports type T = Bool.

Only when you try to build D do you expose the problem that B and C were build against different versions of A, and you can't compare T version 1 against T version 2.

3
votes

The problem is that you cannot link your program against those different versions of package C. A and B have to find a common version of C to use the same implementation of a certain function. One solution to this problem is OSGi but requires stuff like Classloaders which can be used to load different versions of package C in the same process w/o conflicts.

0
votes

One way dependency hell happens is when several different projects you are working on interfere. While a single project has a solvable constraint set, two different project might not and since they're sharing a single package DB, there will be trouble. This variant of dependency hell is solved by cabal sandboxes.