rbenv: A Simple, New Ruby Version Management Tool
rbenv is a new lightweight Ruby version management tool built by Sam Stephenson (of 37signals and Prototype.js fame).
The established leader in the Ruby version management scene is RVM but rbenv is an interesting alternative if you want or need something significantly lighter with fewer features. Think of it as a bit like Sinatra and Rails. It's not about which is the best, it's about which is better for you and your current requirements.
What's the deal with rbenv?
Compared to RVM, rbenv is light. For example, it doesn't include any mechanism to install Ruby implementations like RVM does. Its sole job is to manage multiple Ruby "environments" and it allows you to quickly switch between Ruby implementations either on a local directory or default 'system-wide' basis.
With rbenv, you install Ruby implementations manually or, if you prefer a little help, you can try ruby-build, another project of Sam's that provides RVM esque recipes for installing seven popular Ruby implementation and version combos.
rbenv primarily works by creating 'shim' files in ~/.rbenv/shims which call up the correct version of files for each Ruby implementation behind the scenes. This means ~/.rbenv/shims will be in your path and there's no threat of incompatibilities between libraries or systems like Bundler and rbenv.
The key thing to be aware of, however, is that if you install a gem that includes 'binaries' (or any generally available command line scripts), you need to run rbenv rehash so that rbenv can create the necessary shim files.
How to Install rbenv
Firstly, it's worth noting that by default rbenv is incompatible with RVM because RVM overrides the gem command with a function. This means to get the full rbenv experience you'll need to do a rvm implode to wipe away your RVM installation or, at the least, remove/comment out the RVM loader line in your .bash_profile and/or .bashrc.
The installation instructions for rbenv are likely to change fast due to its youth, so I suggest the README. However, rbenv has just been made into a homebrew package on OS X, so if you're a homebrew user (and if you're not, check out my screencast), try:
brew update
brew install rbenv
rbenv rehashAnd then add this line to your ~/.bash_profile or equivalent:
eval "$(rbenv init -)"When you open a new shell now, you can run commands like rbenv and rbenv version to see what's going on. rbenv versions should return nothing since you won't have any rbenv-enabled Ruby installations yet, so move on to the next step..
Installing Implementations for rbenv
If you have ruby-build installed, getting, say, Ruby 1.9.2-p290 installed is easy:
ruby-build 1.9.2-p290 $HOME/.rbenv/versions/1.9.2-p290If you prefer to download tarballs and do your own Ruby installs, however, you just need to set the directory prefix at the ./configure stage in most cases. For example:
./configure --prefix=$HOME/.rbenv/versions/1.9.2-p290Once you've installed a new Ruby in this way, you need to run rbenv rehash in order for rbenv to create the 'shim' binaries necessary to make the correction version of Ruby available on the path at all times.
The RVM Splashback
In the interests of completeness, it'd be amiss to not mention the minor drama that kicked off on Twitter and Hacker News about rbenv's release.
rbenv made its way on to Hacker News where, surprisingly, many people railed against RVM. This, coupled with a slightly antagonistic tone taken by rbenv's README (which has now been taken away), led RVM's maintainer Wayne E Seguin to vent some pressure on Twitter:
Sam quickly clarified his position:
Nonetheless, Wayne took a little time off, and a campaign to encourage donations to Wayne for his work on RVM was kicked off on Twitter (by Ryan Bates, I believe). The campaign went well, taking RVM's donations from $7468 to $11370 (at time of writing), a jump of almost $4000 in a few days.
Part of the complaint made in rbenv's README was about RVM's "obnoxious" redefinition of the "cd" shell builtin. Essentially, RVM would create a new function which called "cd" but also took into account any .rvmrc files present in each directory so that it could change Ruby version automatically. While there was some validity to this concern, Ben Atkin took some time to write a blog post correcting some of the misinformation on this point.
In the end, however, all seems to be well, and Wayne is already making regular commits to the RVM project again just days later. Hopefully the outpouring of support from the Ruby community for RVM over the past couple of days has shown Wayne that RVM still has a significant user base, most of who aren't going anywhere new anytime soon. If you want to help out, of course, you can still donate to the RVM Pledgie.
Conclusion
If you're happy with RVM, there's not much in rbenv to really leap to. It's just a lighter and more modular way to achieve the basic functionality that RVM provides while missing out on a lot more (although you can use rbenv-gemset to get some basic gemset-like features).
If, however, you want something "lighter" than RVM, rbenv is certainly worth a look. Its approach feels cleaner and more transparent at a certain level, and if this is of utmost importance to you, you may prefer it. I suspect for the most part, however, RVM's well-deserved dominance of this area will be maintained.
[ad] Code School is the interactive online marketplace where you can learn to code directly in the browser and the home of the famous "Rails for Zombies" course (which is free to take!) Other courses include Rails Best Practices, jQuery Air: First Flight, and Functional HTML5 & CSS3.
August 16, 2011 at 2:54 am
Fantastic summary Peter.
August 16, 2011 at 3:53 am
I never understood the reason for "lighter" when discussing tools and frameworks.
"Lighter" just means that the tool does less work and you do more.
I dunno. I'm a freelancer, so for me time is literally money, and RVM is a wonderful tool that handles the extremely boring task of getting different, isolated Ruby versions up and running with 0 effort.
August 16, 2011 at 9:22 am
I'm also very thankfull for RVM. It works so smothly on my machine. But I don't have a problem with several Ruby version management tools being around. But what I definately don't get are the (emotional) "wars" inside the Ruby community. Is that anywhere (like Java or Python) or is it more specific to Ruby? Remember the RSpec drama (and I recently got notice of RubyGems). Please tell me.
As for now, I do understand people not diving much into the community. What for if drama and wars are almost always the result. Respect people.
Thanks to every civilized code commiter, regardless of the language!
August 16, 2011 at 11:04 am
Where there are humans, there is drama. The difference is that Rubyists are better at publishing their thoughts and feelings and the news spreads better. It's not that there's any less drama in other fields, it just doesn't spread as quickly.
August 16, 2011 at 11:37 am
Perhaps the next ruby 2.0 could include these ruby version compatibility solvers.
It tends to arise or occurs when a current software such as redmine or other ruby programs, require one to install an updated early ruby 1.8x rather than simply use the current installed latest version. Rails is also divided into version camps.
It seems redundant once there are new versions and known issues for prior versions.
August 16, 2011 at 1:07 pm
Thanks for the summary. I'll probably try it out at some point, to see for myself. But, since I use a pretty wide set of RVM's features, it's probably not the right tool for me.
Regarding the Drama, I think it's a little misplaced. Not everyone is going to like what you do, so not all feedback is going to be positive. Just because some people who exist don't like something doesn't mean it isn't good. Haters gonna hate.
I also don't understand what people are upset about cd for, it seems pedantic to me. I already had cd overridden with my own function when I first installed RVM, now I just use the hook it provides (doesn't it seem like the builtin cd should offer one?) Anyway, it looks like Wayne's defaulted this behaviour to off (I've already turned it back on) https://github.com/wayneeseguin/rvm/commit/9a9fef58731e822b03789445a859fcdb69e57fff
In the end, I think it's good that we have multiple solutions as it brings new tools and ideas to the table, and increases the probability of finding a solution that is good for a specific situation.
August 16, 2011 at 1:53 pm
A good, objective review. Hopefully things will settle down and people will just choose whichever works for them!
August 16, 2011 at 7:07 pm
TEAM RVM!
Seriously, Wayne is a god among men. He is like the Ruby Jesus. He takes all of our shared pain... all those hours of stressing over installing Ruby and getting your environment *just* right... and he has taken the pain and suffering onto himself. Now, we have no pain at all! Its so super-easy!
August 16, 2011 at 10:57 pm
Thank you very much for writing on this. I am a member of the absolutely hates RVM camp and this lighter version manager looks promising.
Hopefully it is easier than having to add entries in .bash_profile, but managing Rubies through this file is much more easy and less error-prone then the buggy and convoluted RVM.
August 16, 2011 at 11:03 pm
Quote: "Lighter" just means that the tool does less work and you do more.
I have to disagree. Rails is much heavier than it was a few years ago and it now has fewer conventions and more configurations: ie you have to spend more time in the configuration files then you did in Rails 1.
Whether or not Rails is better for it is debatable, and I bounce between each side depending on whether or not I am wasting time wrestling with the overly complex routes file due to forcing REST into Rails.
Of course, I have never needed to create a web-based API and think the idea that beautiful URL's are important is a lot of meaningless noise. I don't create web apps that ever want to be indexed by web crawler. So I am definitely in the minority.
August 18, 2011 at 12:53 am
And yet, Sam is still being incredibly antagonistic. To wit, his latest tweet:
"Seeing reports on Twitter of faster shells for rbenv switchers—a consequence of not loading 8000+ LOC every time you open a new terminal."
The subtext I can't help but hear in this: "RVM loads 8000+ LOC of code, which is an obviously bad design decision."
Instead of extending any good faith that maybe those decisions were made for good reasons -- or, failing that, at least recognizing that Wayne did his damnedest to solve this problem the best he could figure how, and thus word his critique a little more gently, he just goes straight for the attack. I feel like I've seen too much of this behavior out of him to conclude anything less than that he's just an asshole.
You don't see the Sinatra website talking tons of shit about how Rails is slow and bloated, it just speaks to the advantages of Sinatra. Maybe at some level saying that Sinatra takes "minimal effort" implies that there exists something that requires more effort, but it's a much softer slight.
The only parallel I can think of is Ack, whose website (betterthangrep.com) takes an openly hostile stance and lists testimonials and reasons why grep sucks, but I guess since grep has been around forever it feels a little more appropriate.
August 18, 2011 at 8:22 am
"at least recognizing that Wayne did his damnedest to solve this problem the best he could figure how, and thus word his critique a little more gently, he just goes straight for the attack."
I see this sort of thing a lot. "Yeah, it is crap, but I worked hard on it! Give me a cookie"
Who cares? The fact(if it is a fact) that "Wayne did his damnedest to solve this problem the best he could figure how" and RVM is a bloated buggy mess, means that perhaps he shouldn't have released it?
At the end of the day, if you produce crap it doesn't matter if you worked hard on it, or was a slacker. Crap is crap.
Writing 8000 lines of code in a terrible mess of shell scripts, some of which override system commands is never a good idea and there was no good reason for it.
I truly and sincerely hope that if this new version manager ends up working well it takes the place of the De-facto version manager for Ruby. Of course it would be better if multiple versions of Ruby didn't conflict with each other. Java solved the problem, why can't Ruby.
Nothing is more frustrating and downright idiotic when you have 1 Ruby version and 1 JRuby version and typing irb gives you jirb, and before this new program your options were to screw around in .bash or use RVM. arrrrrrggggghhhhhh welcome to amateur hour
August 18, 2011 at 1:38 pm
Nice write-up, Peter. Totally tangential, but what's with the reason for the blur on the @ usernames Wayne referenced? It only deepens a mystery for me. One of those fellows had a pretty funny reply (something along the lines of "what'd i do now?"), and the reference to both of them by Wayne in his tweet puzzled me, I was hoping I'd find out what he meant at some point.
Also, what Hampton said!
August 18, 2011 at 1:45 pm
Thank you for summarising the drama; I've been hugely confused all week.
August 18, 2011 at 4:19 pm
For me it is very important to understand the tools I am using.
I never deeply understood how rvm is working under the hood.
But rbenv is so easy to fully understand how it works.
I just deleted my 7G .rvm directory (with rvm implode) and installed rbenv. For every single project I created a gemset. But with bundler it is not necessary any more. For my old Ruby 2.3 projects I use also Bundler (see http://gembundler.com/rails23.html)
August 18, 2011 at 6:26 pm
Seriously, we need to have an online version of that boxing game where when you win the other guy's head pops up. Maybe we could host it here at rubyinside.com. Whenever there is a war in the Ruby/Rails community, we can set up a "fight", and the people can log in at a certain time and have the video game boxing match, and others can watch. We could have a picture of Peter Cooper as the referee off to the side. The guy who loses can have his head fall off, explode, or his whole body fall to the ground. It could be great fun!
August 18, 2011 at 6:29 pm
I agree with Hampton, 100%.
Managing different Rubies and gemsets for multiple projects with RVM is dead simple. Not to mention using super-convenient .rvmrc files. That's why Wayne's dedication to his project is so appreciated. His work allows every developer to install multiple versions of Ruby and install and manage gems with ease and confidence.
I haven't tried rbenv yet. Maybe later.
September 19, 2011 at 4:33 pm
I didn't try rbenv yet but if it can't install (and remove) a ruby it's not for me. It's too much trouble doing that manually, it's like downloading and compiling gems instead of using gem install, or packages instead of apt-get.
I don't mind if rvm rewrites cd.
Anyway, long live rbenv and long live rvm so that we can work with what we like most.
October 9, 2011 at 3:51 pm
PM, it supports building Rubies via plugin: https://github.com/sstephenson/ruby-build It works just like you'd expect:
rbenv install 1.9.2-p290
I really like that rbenv is modular. Definitely try it out! It's a great little utility.