Hey, Rustom> Does anyone give me a little comparison of these? What would all Rustom> my requirements be? Not sure... these seem important for me Rustom> 1. Need to sandbox not just haskell-projects but ghc (different Rustom> compilations/versions) itself 2. Stability of the (sandboxing) Rustom> tool 3. Correcting the deficiencies of cabal (eg inability to Rustom> uninstall, quarrels between cabal and apt etc) I'll also appreciate users recommandations here. In spite of some decent experience with Haskell and administration, I keep falling regulary into various traps, particulary when in comes to managing cabal with multiple GHCs. Lately, 2 days after a fresh GHC install, a cabal install failed because of version mismatch in a package between system and user database, and I was forced to clear up the whole thing. I'd much prefer to spend my time hacking my haskell software ;) At the moment, my strategy to swap GHC is purely based on the PATH environment, and that works well if you don't forget to set this env before hacking a project. My strategy for cabal is a bit more convoluted, because I had *so many* troubles with multiple databases (AKA system db and user db), I decided that everything would go in the 'system' one, which is actually just in my user-local GHC install, for which my user obviously have required permissions. Things seem to work a bit better that way, I guess because cabal has easier time handling dependencies. So far I avoided the project-local database strategy because my system does not have much computational power, and I'm bored of waiting for ubiquitous packages to compile in all my folders. Arguably, that would be the only safe and simple way to avoid clashes, but I'd appreciate some shared cache to avoid recompiling the same stuff multiple times. Is there some wrappers that can take care of that ? Cheers, -- Paul