Don't forget Bundler. There's a lot of ambivalence to Bundler because of the painful journey to 1.0, but it's totally proportional to the difficulty of the problem, and I think they've really nailed it for 1.0.
In my opinion, Bundler deprecates the need--or at least the need in most cases--to use gemsets. They are still a great feature to give you great control over exactly which gems are installed for testing purposes, but once you switch your applications to using Bundler, there's rarely a need to keep each project in its own gemset.
What Bundler does is establish a container for all gems (and ONLY those gems) that your application needs to run. This is much like an automatic, application-specific gemset.
It also solves the difficult problem of resolving your applications dependencies, locking your gems to a particular set of dependencies to assure consistency across environments and deployments. This is a very critical feature and really showed its ugly head when Rails 2.3.8 was released. Users suddenly found their projects breaking because one gem would load the latest version of activesupport installed on their system (e.g. activesupport-2.3.8) while Rails would require exactly version 2.3.5. Bundler solves this problem by determining that 2.3.5 is the correct dependency and locks the application to only load that version.
It is exactly because of this feature that gemsets are now rarely needed. A large repository of gems will no longer cause you pain and hassle, as Bundler will pick and choose (or install) whichever gems you need to run the project. No more manual management of gemsets. Hooray!
In short, rvm operates at the individual developer level, and bundler at the application level.
rvm gemsets are still a great way to have a general purpose Rails 2 setup and Rails 3 setup on the same machine. Granted, if you only work with applications that use Bundler, it's totally unnecessary. But often you will have legacy apps, or you just want to hack around quickly on some code without set up a Gemfile.
Bundler works together with RVM gemsets. If you have an active RVM gemset, Bundler will use it.
The goal of Bundler is portability between deployments. It answers the question: "How do I package up everything required to run this app so I can deploy it anywhere."
I use RVM for all Ruby installations now. I can't think of a distro or UNIX flavour whose Ruby packages are so good that I would use them instead of RVM. That includes Gentoo, Debian, Ubuntu, CentOS, BSD, OSX.
For those developing Ruby libraries, RVM makes multi-version testing a breeze.
At MWRC 2010 I wandered just outside the auditorium and ran into Wayne. I don't think we'd formerly met before, but we got to chatting and I told him I had played around a bit with RVM, but had some questions/issues.
Holy shit. I got the world's greatest crash course on, not just RVM, but bash scripting as well.
Wayne is not only a really nice guy and fun to hang with, but freakin' smart.
This can't be emphasized enough. Wayne's post about 1.0.0 reveals how close to burn out he was, but on the outside, he is seemingly tireless. He is on #rvm so many hours, quickly answering questions, over and above the work he does coding directly for rvm (not to mention his, you know, paying work and life). Sutto has also been in #rvm a lot over the summer I think.
Wayne is a machine. This guy single-handedly revolutionized ruby installation, due in equal parts to technical chops, and just providing amazingly rock solid free technical support to any and all comers on a daily basis.
I started using this last week to refactor a pile of legacy Ruby code. Gemsets per app is a godsend for that. You can disentangle the giant set of installed gems on your machine, figure out which ones are actual dependencies and which ones are only there because they were part of some crazy experiment six months ago, which ones are only there because they are dependencies of some other gem...
Gemsets for different apps, running MRI vs REE, and really you can run and switch from any flavor of Ruby (including JRuby) in an instant. It handles all the configuration and compilation for installation. Huge time saver, even if you are one of the few that only need one ruby version.
For those who like rvm for its gemsets, check out rip: http://github.com/defunkt/rip . Supports pushing/popping multiple ripenvs (gemsets) and has sweet support for unix-like command plugins.
It's more comparable to virtualenv with virtualenvwrapper. Also, it manages multiple versions of Ruby (AFAIK virtualenv was coupled to a single version of Python) and has a per-directory dotfile (that way, when I switch to ~/Projects/something rvm automatically switches to correct ruby and gemset).
It generally feels more 'complete' to me.
I didn't do any serious work with virtualenv in quite some time, so this may have changed.
virtualenv -p python2.5 will create a virtualenv with the Python 2.5 interpreter. I like the per-directory dotfile approach for autodetecting/activating a virtual ruby setup.
Are you sure about that? .rvm/scripts/cd still has this at the top [1]:
# Source a .rvmrc file in a directory after changing to it, if it exists.
# To disable this fature, set rvm_project_rvmrc=0 in $HOME/.rvmrc
Also, the new security features that Wayne mentions in this post suggest that a cd automatically leads to a check on the directory you cd into. Doesn't that imply that rvm still has to plug itself into cd? (I may be confused here.)
I have to admit the cd thing ended up throwing me for an interesting loop at one point. I was scripting and no matter what happened, cd was returning 0 (success) - even when the cd command was actually failing. I could not figure out for the life of me why the right exit status wasn't being reported. It turns out that rvm wasn't saving and then returning the exit status of cd itself. (So the exit status I was capturing wasn't actually that of cd.)
Long story short, two minutes in #rvm and Wayne had it fixed [2].
Edit: I think I see the confusion. Cldwalker is saying that he doesn't like rvm tinkering with cd. Bgentry is saying that rvm no longer automatically switches Ruby if it finds a .rvmrc in a folder (after you cd into it). That's right, but it doesn't change what is bothering Cldwalker: rvm does in fact still get in front of cd. (I think 'hijacking' is too strong, but I know what Cldwalker means by it.) If you use rvm, then by default every time you issue cd, rvm runs the code in [1] (part of which obviously punts to the built-in cd). You can disable this behavior, as Cldwalker says, by setting the environment variable rvm_project_rvmrc to 0. Unless I'm wrong, the default is still on.
So, setting rvm_project_rvmrc=0 will still execute RVM's cd script, but it will skip the part that loads an rvmrc
Not exactly: setting 'rvm_project_rvmrc=0' causes rvm's cd script to immediately bail out. From .rvm/scripts/cd:
if [[ "$rvm_project_rvmrc" -ne 0 ]] ; then
Everything else in the cd script hangs off that if. So by setting the environment variable, that whole branch (which is the whole script) is skipped and rvm won't get in front of cd.
Save so much time and energy with this tool. Realized how much more I get done on a daily basis because of it and almost felt guilty not to donate a few bucks.
+ Rubinius will remove the GIL ("the work has already begun" -- Yehuda Katz http://yehudakatz.com/2010/08/14/threads-in-ruby-enough-alre...)
+ MacRuby will be even faster, more stable and more documented
It will be an awesome end of 2010/2011 for Ruby programmers.