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">&lt;<a href="mailto:rwallace@thewallacepack.net" target="_blank">rwallace@thewallacepack.net</a>&gt;</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>
&quot;fixed&quot; libraries (&quot;text&quot;, &quot;mtl&quot;, &quot;transformers&quot;, and &quot;parsec&quot;).  Any<br>
plans to make these not have to be fixed? Or is there a trick I&#39;m<br>
missing?<br>
<div class="HOEnZb"><div class="h5"><br>
On Sun, Sep 2, 2012 at 11:25 AM, Danny B &lt;<a href="mailto:danny.b.eml@gmail.com">danny.b.eml@gmail.com</a>&gt; wrote:<br>
&gt; Like many of us, I&#39;ve suffered from cabal dependency hell and sought relief.<br>
&gt;<br>
&gt; I wasn&#39;t exactly happy with sandboxes - because using per-project ones<br>
&gt; meant package duplication and shared sandboxes suffer from the same<br>
&gt; issues as the GHC package database itself, i.e. reinstalls can break<br>
&gt; other projects, etc. So I wrote hellno, which is so named because that&#39;s<br>
&gt; the expression one makes when seeing cabal hell suddenly manifest itself<br>
&gt; and that&#39;s also the expression one makes upon encountering yet ANOTHER<br>
&gt; cabal wrapper.<br>
&gt;<br>
&gt; To quote the README:<br>
&gt;&gt; Generally, with hellno you&#39;ll get the same result as for blowing away your user<br>
&gt;&gt; package database and doing a nice clean install but without having to recompile<br>
&gt;&gt; everything and with ability to easily revert back and change between projects.<br>
&gt;<br>
&gt; Hellno works by keeping all the compiled packages to itself in a<br>
&gt; database, so that when you ask it to bring in the dependencies of a<br>
&gt; project, it will use the precompiled packages if available or install<br>
&gt; the deps and save them for later reuse.<br>
&gt;<br>
&gt; Hellno puts symlinks in the user package database pointing to packages<br>
&gt; in its storage to make them visible. Mutating the user db is hardly<br>
&gt; elegant, although shouldn&#39;t result in much trouble.<br>
&gt;<br>
&gt; It&#39;s been working fine for me, so I figured it may be useful to others.<br>
&gt; You can get hellno from GitHub:<br>
&gt; <a href="https://github.com/db81/hellno" target="_blank">https://github.com/db81/hellno</a><br>
&gt;<br>
&gt; I don&#39;t mean to say that sandboxing is inherently bad or should not be<br>
&gt; used, but I guess it&#39;s better to consider more than one way.<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Haskell-Cafe mailing list<br>
&gt; <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
&gt; <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>