On Tue, Nov 8, 2011 at 1:43 AM, Paul R
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.
This is the best solution I'm currently aware of, but there are ways we could improve on this (involving new sandboxing tools; similar to NixOS).
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.
I strongly caution against doing this. My advice is: (explanations below) 1) /never/ install anything into your system db: 2) /never/ explicitly install packages that come with ghc (the packages that are in your system db) 3) don't rely on your user package db for development -- it's a convenient place to put things you want to use in ghci, and it's the simplest thing to use when installing Haskell applications (such as cabal, cabal-dev, cab, etc...) 4) use cabal-dev for all development. Explanations: (1): Installing to your system package db will prevent you from sandboxing builds in the context of the Haskell package system. You can restrict to individual ghcs, since each ghc has it's own system db, but you can't prevent your installed package versions from causing your builds to behave differently than my builds -- as a result, you may not realize that your package version bounds are broken, for example. You'll also not notice when new versions of dependencies cause your build to break, and you may experience failures when building other packages because you have a different set of installed dependencies than the developer expected. (1 & 2): These things, together, will prevent you from having version conflicts between the system and user dbs. Furthermore, cabal-dev doesn't hide the system db (the tools cabal-dev uses don't expose an api that enables that in the way that the user db can be hidden, and the libraries installed in the system db by ghc usually can't be upgraded/reinstalled without upgrading ghc anyway). (3) It's impractical to keep your user db clean enough to accomplish the same objectives of sandboxed builds -- you /can/ do it, but I don't think it's worth the effort when other tools exist to help (cabal-dev being my current hammer, capri should also do it, but I haven't personally had success with capri). (4) I'm sorry that cabal-dev adds computational overhead -- this generally isn't an issue when compared to the long-term issues that come up as a result of dependency resolution /without/ a sandbox, but I realize that there are situations where cabal-dev can cause build times to take significantly longer. Ideas / suggestions / patches / etc. are happily considered :) --Rogan
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
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe