Dependency hell in cabal. It is really a hell

6
votes

Different programming languages use different packaging systems.

In their varied approach, Java's Maven looks like the best bet for me since it maintains different version of jar files in seperately versioned folders and hence, there is no way one will end up in conflicting versions of a library.

Next comes python. Python's pip puts its packages into /usr/local/lib/python/dist-packages/site-packages. When there is a version conflict, one can use its virtualenv and live with it.

Nodejs supports installing packages both in local folders and global folders. Till date for me, i never had a dependency conflict in the global libraries.

Then I got fascinated by the haskell's style and started using cabal. First, i was installing my libraries inside /home/user1/.cabal. Then when the package system broke, one friend suggested me to remove two folders - /home/user1/.cabal && /home/user1/.ghc. Now, my first confusion arose, why does cabal's library files sit in two folders .cabal && .ghc. I cleaned the library folders, ~/.ghc and ~/.cabal and did cabal install from a package source for cabal-db-0.1.12. Now, there was a new error and i was surprised, because i had sanitized all local repositories. The error was, 

Configuring Cabal-1.22.2.0...
Building Cabal-1.22.2.0...
Installed Cabal-1.22.2.0
cabal: Error: some packages failed to install:
ansi-terminal-0.6.2.1 failed during the configure step. The exception was:
user error (The package 'ansi-terminal' requires Cabal library version -any &&
>=1.6 but no suitable version is installed.)

Then I tried the safest bet - sandbox for cabal-db. It worked. Then i repeated sandboxing for another pacakge, ghc-pkg-autofix. I did,

cd ghc-pkg-autofix-0.2.0.1
cabal sandbox init
cabal install

And for sandbox where there are absolutely no external dependencies, there are errors again,

cabal: Could not resolve dependencies:
trying: ghc-pkg-autofix-0.2.0.1 (user goal)
trying: Cabal-1.22.2.0 (dependency of ghc-pkg-autofix-0.2.0.1)
next goal: process (dependency of ghc-pkg-autofix-0.2.0.1)
rejecting: process-1.2.0.0/installed-06c..., 1.2.3.0, 1.2.2.0, 1.2.1.0,
1.2.0.0, 1.1.0.2, 1.1.0.1, 1.1.0.0 (conflict: ghc-pkg-autofix => process>=1.0
&& <1.1)
rejecting: process-1.0.1.5, 1.0.1.4, 1.0.1.3, 1.0.1.2, 1.0.1.1, 1.0.0.0
(conflict: Cabal => process>=1.1.0.1 && <1.3)
Dependency tree exhaustively searched.

Note: when using a sandbox, all packages are required to have consistent
dependencies. Try reinstalling/unregistering the offending packages or
recreating the sandbox.

Am i doing something wrong (or) this kind of dependency conflicts are quite common in cabal? I see, managing dependencies in other languages are a lot simpler.

Note: I use cabal-install version 1.22.0.0 && The Glorious Glasgow Haskell Compilation System, version 7.8.4

1
haskellcabal
nope it's not common - but very common for beginners. Indeed the easiest way for beginners is IMHO to setup a clean environment and use sandboxes. There is a nice tutorial on how to do it here (you don't have to use the stackage parts if you don't want to - if you have GHC 7.10.1 you actually cannot AFAIK) - btw: did you use cabal-1.22 on purpose (i.e. with GHC 7.10.1?) because using Haskell plattform I would not right now) - Random Dev
btw: just curious - how does maven handle the situation where Package X depends on A-Vers1 and Y on a-Vers2 (not compatible) and you want to use both X and Y? - Random Dev
Inside M2_HOME repository, maven will create two folders like A/1.0.0/* and A/2.0.0/*. Since the global repository uses seperate folders based on versions, different versions of same archetype/jar can sit inside your system in one place. - user2879704
@MadhavanKumar That's nice for the packages for just sitting there, but what if I want to actually use those libraries? Java doesn't allow you to load multiple classes of the same name into the VM at the same time, or when you can make it do that, you will get really weird exceptions when you use them. - Sebastian Redl
@SebastianRedl exactly - the problem is still there you just get at it a bit later - Random Dev

1 Answers

5
votes

"And for sandbox where there are absolutely no external dependencies" this is not true. A sandbox still has dependencies on the global package database. Things like Cabal, GHC, process are typically installed in the global package database. Here you want to install ghc-pkg-autofix which requires process 1.0, but you have a more recent version of process already installed. Are you sure you need ghc-pkg-autofix, it seems to be quite old.