Safer Haskell Install

update (28 march 2015): I now use Haskell LTS instead of a random stackage version.

If you are on windows, just download the Haskell Platform and follow the instruction to use Haskell LTS.

If you want to know the why and the how; you should read the entire article.

Why?

The main weakness of Haskell as nothing to do with the language itself but with its ecosystem1.

The main problem I’ll try to address is the one known as cabal hell. The community is really active in fixing the issue. I am very confident that in less than a year this problem will be one of the past. But to work today, I provide an install method that should reduce greatly two effects of cabal hell:

dependency error

lost time in compilation (poor polar bears)

With my actual installation method, you should minimize your headache and almost never hit a dependency error. But there could exists some. If you encounter any dependency error, ask gently to the package manager to port its package to stackage.

It installs some useful binaries that might cause compilation error if not present.

As the version of libraries is fixed up until you update the Haskell LTS version, you should never use cabal sandbox. That way, you will only compile each needed library once. The compiled objects/binaries will be in your ~/.cabal directory.

Some Last Words

This script use the latest Haskell LTS. So if you use this script at different dates, the Haskell LTS might have changed.

While it comes to cabal hell, some solutions are sandboxes and nix. Unfortunately, sandboxes didn’t worked good enough for me after some time. Furthermore, sandboxes forces you to re-compile everything by project. If you have three yesod projects for example it means a lot of time and CPU. Also, nix didn’t worked as expected on OS X. So fixing the list of package to a stable list of them seems to me the best pragmatic way to handle the problem today.

From my point of view, Haskell LTS is the best step in the right direction. The actual cabal hell problem is more a human problem than a tool problem. This is a bias in most programmer to prefer resolve social issues using tools. There is nothing wrong with hackage and cabal. But for a package manager to work in a static typing language as Haskell, packages must work all together. This is a great strength of static typed languages that they ensure that a big part of the API between packages are compatible. But this make the job of package managing far more difficult than in dynamic languages.

People tend not to respect the rules in package numbering2. They break their API all the time. So we need a way to organize all of that. And this is precisely what Haskell LTS provide. A set of stable packages working all together. So if a developer break its API, it won’t work anymore in stackage. And whether the developer fix its package or all other packages upgrade their usage. During this time, Haskell LTS end-users will be able to develop without dependency issues.

By ecosystem of a language I mean, the community, the tools, the documentations, the deployment environments, the businesses using the language, etc… Mainly everything that has nothing to do with the detail of a programming language but has to do on how and why we use it.↩