<spanclass="tomenu"><ahref="#navigation">↓ Menu ↓</a></span>
<spanclass="flush"></span>
</div>
</div>
<divid="titre">
<h1>Safer Haskell Install</h1>
</div>
<divclass="flush"></div>
<divid="afterheader"class="article">
<divclass="corps">
<div>
<imgsrc="../../../../Scratch/img/blog/Safer-Haskell-Install/main.jpg"alt="to Haskell and Beyond!!!"/>
</div>
<divclass="intro">
<p><spanclass="sc"><abbrtitle="Too long; didn't read">tl;dr</abbr>: </span> Install Haskell (OS X and Linux only) by pasting the following in your terminal:</p>
<p><em>update (28 march 2015): I now use <ahref="http://www.stackage.org/lts">Haskell LTS</a> instead of a random stackage version.</em></p>
<p>If you are on windows, just download the Haskell Platform and follow the instruction to use <ahref="http://www.stackage.org/lts">Haskell LTS</a>.</p>
<p>If you want to know the why and the how; you should read the entire article.</p>
</div>
<h2id="why">Why?</h2>
<p>The main weakness of Haskell as nothing to do with the language itself but with its ecosystem<ahref="#fn1"class="footnote-ref"id="fnref1"><sup>1</sup></a>.</p>
<p>The main problem I’ll try to address is the one known as <em>cabal hell</em>. 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:</p>
<ul>
<li>dependency error</li>
<li>lost time in compilation (poor polar bears)</li>
</ul>
<p>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 <ahref="http://www.stackage.org">stackage</a>.</p>
<p>So to install copy/paste the following three lines in your terminal:</p>
<p>You can read the script and you will see that this is quite straightforward.</p>
<oltype="1">
<li>It downloads the latest <code>GHC</code> binary for you system and install it.</li>
<li>It does the same with the <code>cabal</code> program.</li>
<li>It updates your cabal config file to use <ahref="http://www.stackage.org/lts">Haskell LTS</a>.</li>
<li>It enable profiling to libraries and executables.</li>
<li>It installs some useful binaries that might cause compilation error if not present.</li>
</ol>
<p>As the version of libraries is fixed up until you update the <ahref="http://www.stackage.org/lts">Haskell LTS</a> 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 <code>~/.cabal</code> directory.</p>
<h2id="some-last-words">Some Last Words</h2>
<p>This script use the latest <ahref="http://www.stackage.org/lts">Haskell LTS</a>. So if you use this script at different dates, the Haskell LTS might have changed.</p>
<p>While it comes to cabal hell, some solutions are sandboxes and <code>nix</code>. 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, <code>nix</code> 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.</p>
<p>From my point of view, <ahref="http://www.stackage.org/lts">Haskell LTS</a> 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.</p>
<p>People tend not to respect the rules in package numbering<ahref="#fn2"class="footnote-ref"id="fnref2"><sup>2</sup></a>. They break their API all the time. So we need a way to organize all of that. And this is precisely what <ahref="http://www.stackage.org/lts">Haskell LTS</a> 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, <ahref="http://www.stackage.org/lts">Haskell LTS</a> end-users will be able to develop without dependency issues.</p>
<hr/>
<pclass="small">
<ahref="https://www.flickr.com/photos/nesster/4198442186/">The image of the cat about to jump that I slightly edited can found here</a>
</p>
<sectionclass="footnotes">
<hr/>
<ol>
<liid="fn1"><p>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.<ahref="#fnref1"class="footnote-back">↩</a></p></li>
<liid="fn2"><p>I myself am guilty of such behavior. It was a beginner error.<ahref="#fnref2"class="footnote-back">↩</a></p></li>
