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](http://hackage.haskell.org/package/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.