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
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
Hell yeah!
Looks like a nice approach.
On Sun 02 Sep 2012 19:25:08 BST, 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
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 m...@nh2.me wrote:
Hell yeah!
Looks like a nice approach.
On Sun 02 Sep 2012 19:25:08 BST, Danny B wrote:
Like many of us, I've suffered
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?
On Sun, Sep 2, 2012 at 11:25
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
rwall...@thewallacepack.net wrote:
I like the
On Mon, Sep 3, 2012 at 3:15 PM, Richard Wallace
rwall...@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
