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