RVM vs RBENV……

Just installed a new precise pangolin and thought of giving rbenv a try….

So collected this with a bit of googling….

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  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.

INSTALL

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 rehash

And 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-p290

If 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-p290

Once 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 personally switched back to rvm coz I am getting openssl error which is tricky(ofcourse mybad!) and not able to get over it…