perhaps the *right* solution is to view that as a bootstrap build, and then have hellno build itself? :)<div>That said, its also an executable rather than library, so its not quite the same problem.<br><br><div class="gmail_quote">
On Sun, Sep 2, 2012 at 11:15 PM, Richard Wallace <span dir="ltr"><<a href="mailto:rwallace@thewallacepack.net" target="_blank">rwallace@thewallacepack.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I like the approach so far. But hellno itself seems to have several<br>
dependencies itself. So installing with cabal pulls these in as<br>
"fixed" libraries ("text", "mtl", "transformers", and "parsec"). Any<br>
plans to make these not have to be fixed? Or is there a trick I'm<br>
missing?<br>
<div class="HOEnZb"><div class="h5"><br>
On Sun, Sep 2, 2012 at 11:25 AM, Danny B <<a href="mailto:danny.b.eml@gmail.com">danny.b.eml@gmail.com</a>> wrote:<br>
> Like many of us, I've suffered from cabal dependency hell and sought relief.<br>
><br>
> I wasn't exactly happy with sandboxes - because using per-project ones<br>
> meant package duplication and shared sandboxes suffer from the same<br>
> issues as the GHC package database itself, i.e. reinstalls can break<br>
> other projects, etc. So I wrote hellno, which is so named because that's<br>
> the expression one makes when seeing cabal hell suddenly manifest itself<br>
> and that's also the expression one makes upon encountering yet ANOTHER<br>
> cabal wrapper.<br>
><br>
> To quote the README:<br>
>> Generally, with hellno you'll get the same result as for blowing away your user<br>
>> package database and doing a nice clean install but without having to recompile<br>
>> everything and with ability to easily revert back and change between projects.<br>
><br>
> Hellno works by keeping all the compiled packages to itself in a<br>
> database, so that when you ask it to bring in the dependencies of a<br>
> project, it will use the precompiled packages if available or install<br>
> the deps and save them for later reuse.<br>
><br>
> Hellno puts symlinks in the user package database pointing to packages<br>
> in its storage to make them visible. Mutating the user db is hardly<br>
> elegant, although shouldn't result in much trouble.<br>
><br>
> It's been working fine for me, so I figured it may be useful to others.<br>
> You can get hellno from GitHub:<br>
> <a href="https://github.com/db81/hellno" target="_blank">https://github.com/db81/hellno</a><br>
><br>
> I don't mean to say that sandboxing is inherently bad or should not be<br>
> used, but I guess it's better to consider more than one way.<br>
><br>
> _______________________________________________<br>
> Haskell-Cafe mailing list<br>
> <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
> <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br></div>