RVM (at http://rvm.beginrescueend.com) is a rather nice tool for managing multiple ruby installations - it gives support for switching between ruby environments (similar to gcc_select and friends), and also exporting lists of packages so that you can easily bring up a given set of gems in any of the interpreters. Do we have any similar system for ghc/cabal? I quite frequently find myself switching between 6.10 and 6.12 for various things, and it's always a bit painful to get your environment up to speed. Is there a golden road for this stuff, or do the compiler hackers here just munge the PATH? cheers Mark
I wrote it: It's called Hack-Nix and utilizies the Nix repository manager. I've added a wiki page to haskell.org some time ago. Drawbacks: Right now it doesn't make sense to include all hackage packages because resolving dependencies would never end because its written in Nix language. I can show you how it works if you're interested. Marc Weber
On Mar 16, 2010, at 20:59 , Mark Wotton wrote:
Do we have any similar system for ghc/cabal? I quite frequently find myself switching between 6.10 and 6.12 for various things, and it's always a bit painful to get your environment up to speed. Is there a golden road for this stuff, or do the compiler hackers here just munge the PATH?
Both the system and user package databases handle multiple compiler versions, and Cabal inherits this so should do the right thing for the most part. The GHC environment I've assembled for campus machines installs versioned commands (including adding versions to the commands that lack them), then a script uses the machine configuration db to install symlinks for the default version. This is slightly less convenient than using $PATH, and I may alter it to allow PATH munging and then use something like http://modules.sf.net/ to make it easier for users. (I have been reworking our Perl setup to allow for this, and would like to do the same for Python, Ruby, and some of the commercial packages for which we provide multiple versions.) Admittedly this still requires manually installing libraries in all available compiler versions. I'm not aware of any automated way to deal with this, but then I'm not aware of one for Perl or Python either (both of which we handle similarly to GHC). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
2010/03/16 Brandon S. Allbery KF8NH
On Mar 16, 2010, at 20:59 , Mark Wotton wrote:
Do we have any similar system for ghc/cabal? I quite frequently find myself switching between 6.10 and 6.12 for various things, and it's always a bit painful to get your environment up to speed. Is there a golden road for this stuff, or do the compiler hackers here just munge the PATH?
Both the system and user package databases handle multiple compiler versions, and Cabal inherits this so should do the right thing for the most part.
The GHC environment I've assembled for campus machines installs versioned commands (including adding versions to the commands that lack them), then a script uses the machine configuration db to install symlinks for the default version.
While I've not worked with it much, Nix seems like a complete, well-thought system for building out multi-versioned package installations. Have you looked at it? What do you think? Finding myself in a similar situation, I wonder if it's not ultimately better to leverage the work of the Nix team, instead of building a "simpler" system for Haskell (and then later for Ruby and then...). -- Jason Dusek
participants (4)
-
Brandon S. Allbery KF8NH -
Jason Dusek -
Marc Weber -
Mark Wotton