[Haskell-cafe] hellno - a somewhat different approach to tackling cabal hell
danny.b.eml at gmail.com
Mon Sep 3 17:01:46 CEST 2012
On 09/03/2012 02:15 PM, Richard Wallace wrote:
> I like the approach so far. But hellno itself seems to have several
> dependencies itself. So installing with cabal pulls these in as
> "fixed" libraries ("text", "mtl", "transformers", and "parsec"). Any
> plans to make these not have to be fixed? Or is there a trick I'm
You can simply delete them manually after installing hellno due to GHC
using static linkage.
Or if you want a dirty and hackish trick, you can load up the source in
GHCi and call grabPackage with their PackageIds :) I thought about
making a command that would allow you to do this, but after using it you
can easily end up with your fixed package set being broken, so I'm not sure.
> On Sun, Sep 2, 2012 at 11:25 AM, Danny B <danny.b.eml at gmail.com> wrote:
>> Like many of us, I've suffered from cabal dependency hell and sought relief.
>> I wasn't exactly happy with sandboxes - because using per-project ones
>> meant package duplication and shared sandboxes suffer from the same
>> issues as the GHC package database itself, i.e. reinstalls can break
>> other projects, etc. So I wrote hellno, which is so named because that's
>> the expression one makes when seeing cabal hell suddenly manifest itself
>> and that's also the expression one makes upon encountering yet ANOTHER
>> cabal wrapper.
>> To quote the README:
>>> Generally, with hellno you'll get the same result as for blowing away your user
>>> package database and doing a nice clean install but without having to recompile
>>> everything and with ability to easily revert back and change between projects.
>> Hellno works by keeping all the compiled packages to itself in a
>> database, so that when you ask it to bring in the dependencies of a
>> project, it will use the precompiled packages if available or install
>> the deps and save them for later reuse.
>> Hellno puts symlinks in the user package database pointing to packages
>> in its storage to make them visible. Mutating the user db is hardly
>> elegant, although shouldn't result in much trouble.
>> It's been working fine for me, so I figured it may be useful to others.
>> You can get hellno from GitHub:
>> I don't mean to say that sandboxing is inherently bad or should not be
>> used, but I guess it's better to consider more than one way.
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
More information about the Haskell-Cafe