BestPractices

Best Practices

Using cabal-dev

For projects with a working *.cabal file

Let us assume that you have a large number of projects, say 10, you are working on. Each of these projects requires different libraries. In a typical scenario, these libraries are (i) globally installed or (ii) are installed into ~/.cabal. Both approaches assume that the different libraries play well with each other and various sub-dependencies. Parsec, for example, tends to be recompiled time and again on my system when I jump between projects. Mostly because of changes in the underlying dependencies.

cabal-dev solves this by providing a local directory for each project, where installed libraries are kept. That means that library dependencies have to be sane only within one project, not multiple ones.

cabal-dev provides an additional very nice option. It is extremely easy to use experimental libraries without having to install them globally (neither system-globally nor user-globally). Say, I want to patch the bio library for exactly one project; instead of having to install this patched library under ~/.cabal I can just cabal-dev add-source my-bio and use it for the one project that needs it.

1. install cabal-dev
2. execute cabal-dev init
3. execute cabal-dev install-deps
4. a local environment now lives under cabal-dev; the folder can be deleted at will
5. execute cabal-dev ghci to get into interactive mode
6. read the help for further info (e.g. cabal-dev add-source)

The above commands provide a localized environment for each new project which should help with Haskell's own version of DLL hell ;-)

There are two main drawbacks:

1. You need more space; for typical users this is not more than a few megabyte for each project -- I do not care about it
2. Libraries are compiled for each project. So instead of compiling parsec once, you compile it once for each project. Go, have a coffee while waiting.