awesome! I look forward to playing with this and hopefully saying "hell yeah" when i'm done :) -Carter On Sun, Sep 2, 2012 at 2:51 PM, Niklas Hambüchen wrote:

Hell yeah!

Looks like a nice approach.

...

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

On Sun 02 Sep 2012 19:25:08 BST, Danny B wrote: 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

perhaps the *right* solution is to view that as a bootstrap build, and then have hellno build itself? :) That said, its also an executable rather than library, so its not quite the same problem. On Sun, Sep 2, 2012 at 11:15 PM, Richard Wallace < rwallace@thewallacepack.net> 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?

...

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

On Sun, Sep 2, 2012 at 11:25 AM, Danny B wrote: 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

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 missing?

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 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