Re: [Haskell-cafe] hellno - a somewhat different approach to tackling cabal hell

On Mon, Sep 3, 2012 at 3: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 missing?

All of those libraries are included in the Haskell Platform anyway. The majority of users shouldn't need to install extra packages to get it to work.

On Sun, Sep 2, 2012 at 11:25 AM, Danny B 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: https://github.com/db81/hellno

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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe