In an ideal world, we wouldn't need software to switch Ruby versions. In an
ideal world, we wouldn't need Ruby versions at all.
Matz would simply have been
struck by divine inspiration and shared his vision of the perfect programming
language with the world, including every feature that would be added over time
to Ruby in our flawed universe (fully optimized, of course). Alas, we do not
live in a perfect world, and that's simply not how languages are designed
(despite what some Scala fans will tell you). It's not all bad. Matz
is famously nice
in our world. If Ruby would have happened the other way, he might not have been
as nice. The fame certainly would have gone to my head.
In any event, we live in a universe with versions, and working on more than one
Ruby app frequently means switching back and forth between them numerous times
a day. The good news is that this doesn't take much thought nowadays, thanks to
Ruby version management tools. Honestly, if you're the target audience for this post, you
probably already know what these do, but just in case, these are pieces of
software that help you maintain separate Ruby installations for each version
of Ruby that you need on your system and switch between them at will. That way,
you can run code for your super-disruptive, VC-ready social something-or-other
on the newest, fastest Ruby and code that's not worth the trouble of updating on
whatever Ruby it was written for. Four tools, all free and open-source, dominate
the landscape: RVM, rbenv, chruby, and ry. (Others have been
historically popular but have since been deprecated.) I've seen posts that
compare RVM to rbenv or rbenv to chruby, but nothing covering the whole gamut.
I decided I would try to fill that gap, so I've put together a rundown of what
the state of Ruby version management is today, and which tool is the best for
Ultimately, what we want these programs to do is manipulate your system PATH
variable, so that when you type "ruby" and hit enter, your system finds the
right Ruby. There are many ways to do this, but the aforementioned tools use
- RVM and chruby change your
PATH every time you switch Rubies so that your chosen Ruby is given priority.
- rbenv adds a directory of "shims" to your PATH. The shims are small
executables with the same names as Ruby executables, i.e.,
rack, etc... This causes a shim to be run when you try to run the
corresponding Ruby executable. The shim invokes rbenv, which then figures out
the correct Ruby to run.
- ry adds a location to your path that is symlinked
to the Ruby of your choice. When you switch Rubies, ry updates the symlink.
I had originally planned to go through these one-by-one, giving the pros and
cons, but it was too easy to get lost in edge cases and minor details that most
users don't need to know. So here's the approach I'm recommending instead: write
down the four version managers I've introduced, and read through the headings
below. If one applies to you, stop and read. Otherwise, you can skip that
section. At the end of the article, you'll probably have crossed a few off, and
you'll know what will work for you.
I'm joining a team that already has a preferred version manager.
Use theirs. You don't want to be the person that can't change your config with
everyone else because you decided to be different. It would be a different story
if one of these tools were clearly less reliable than the others, but they all
do an excellent job.
Cross off chruby and ry. RubyMine is planning to add chruby support, but it
hasn't happened yet.
I want my machine to automatically use the right Ruby for the project I'm working on.
Cross off ry. It doesn't support automatic version switching.
rbenv inherently supports this. Since every invocation of
there's nothing to update when you switch Rubies.
RVM and chruby support this by updating when you
cd into a project directory.
...and my team has .rvmrc or .ruby-version files in its projects.
.rvmrc is only used by RVM. Use RVM if you want to use the settings within it.
.ruby-version is read by RVM, rbenv, and chruby, but RVM is more generous with
matching than the others. rbenv and chruby expect the file to correspond exactly
with the name of a version of Ruby that you have, e.g.
ree-1.8.7-2011.12. RVM will accept
1.9.2 and select whatever patch level of
Ruby 1.9.2 you have installed. If you want to accept
.ruby-version files that
contain versions without patch levels, use RVM.
...and I never, ever want to interact with my version manager.
The downside to rbenv's shim method is that you use the same set of shims for
every project. If the executables that you can run change, the shims can become
out-of-date. You have to run
rbenv rehash when this happens. If this is a
dealbreaker for you, either avoid rbenv or install the rbenv-gem-rehash plugin,
which runs rehash every time you install a gem.
I want to keep the gems I use for each project separate and Bundler does not meet my needs.
RVM includes a feature called "gemsets" that allows you to run each project in
its own sandbox of gems. rbenv also supports this through a plugin called
I want a GUI.
RVM has an official OS X GUI called JewelryBox.
I need to run Ruby 1.8.7 or Ruby Enterprise Edition.
chruby and rbenv do not include Ruby installation support by design. These are
commonly paired with either ruby-build, ruby-install, or RVM (which provides an
executable called mrvm that exclusively installs Rubies) to install the Rubies
to be managed. ruby-install does not support Ruby 1.8.7, so be sure to pair
rbenv or chruby with one of the others if this is a need of yours.
It behooves me to mention that Ruby 1.8.7 is end-of-life, and you probably still
will have to do funny things to get it to install on the newest OS X or Linux.
If at all possible, it might be more efficient to move the project you're using
it for to 1.9.3, at least.
cd makes me nervous.
RVM's auto-switching is enabled by overriding
cd in the terminal. If you don't
like this, either disable automatic version detection or don't use RVM. If you
like the installation capabilities of RVM but would rather use chruby or rbenv
for automatic selection, RVM provides a tool called mrvm for just that purpose.
Do one thing, and do it well.
chruby only switches your Ruby version. It does not install Ruby. It does not
have plugins. Its creator sees feature creep as an infection. If these
statements resonate with you, consider chruby. It pairs nicely with ruby-install,
which installs versions of Ruby and does nothing else.
I want to be able to read the code I run.
chruby and ry are both set up very simply and can be read with relative ease.
chruby prides itself on being only 90-ish lines.
I want to be able to use Rubies installed in scattered folders.
Only chruby will let you specify multiple arbitrary locations for your Ruby
installations. RVM, rbenv, and ry all expect for your ruby installations to
be contained within one folder, though they do let you specify which folder that
is. If you can't keep all of your Ruby installation directories within one
parent directory, you'll need to either use chruby or add symlinks to make them
appear in your RVM/rbenv/ry home directory.
So which one should I use?
Let's see how your list is looking. If there's only one that hasn't been crossed
off, congratulations. Meet your new ruby version management tool. If not, well,
we just have to accept that there is a variety of free-as-in-freedom tools that
perform this job admirably. Unfortunately. I say it's unfortunate because I
know it's easy to agonize over what tool is best for the task at hand when
there's no clear answer and to worry that you'll pick incorrectly and become
entrenched in a workflow that you find out is sub-optimal after it's far too
late to change. It's vim vs. emacs all over again. Perhaps the First-Worldliest
of the First-World Problems. In this case, if the use cases I went over haven't made
one of them the clear choice, just pick one from the ones you have left. Roll a
die. The conventional wisdom is that chruby is a good choice if you fancy
yourself a hacker or power user, RVM is nice if you just want things to work
without worrying about technical details, and rbenv is somewhere in the middle.
Perhaps that pushes you in one direction, but even if it doesn't, don't let it
bother you and move on with something. Odds are, you won't regret it.