Home > Development, Linux, News > what you should know about rbenv and RVM

what you should know about rbenv and RVM

November 1st, 2011

By now you have most likely heard of RVM and rbenv. (There is no mistake in writing one in uppercase and second in lowercase, I’m just following conventions given by their respective authors.) As a contributor in the RVM Project I thought I could find out what really rbenv does. Reading the sources gave me some insights into rbenv – unfortunately there was no new shell trick to learn for me from rbenv. Still I could understand how it works and find differences between the two tools. Both claim, and do provide, a way to switch the currently active ruby.

The main difference between them is when the ruby is switched.

  • For RVM, it’s during changing directories – the process is done once, and from now on the shell already has all ruby and gem binaries available. This can also be triggered manually.
  • For rbenv, all ruby and gem binaries are always available in shell but will load proper code only when in proper context – so switching is done each time any binary is executed.

Going into more details: RVM will take about 60ms on every called cd, which means you would need to type over 16 cd commands to take a whole second – try to do that. During the directory change, RVM will set up environment variables to reflect your ruby and gemset selection allowing it to be separated from other rubies and gems, or binaries. You will not be able to run any other binary or gem available in another project, and any auto-loading mechanisms using plugins will not be able to load them from other project environment.

For rbenv, switching directories with cd takes no time (0ms) so it is faster by default for changing directories. After installing some gems, you need to rehash and it takes 60ms. Using ruby or switching to a project dir does not change the user’s environment almost at all, except for the RBENV_VERSION variable for current – but it does not mean the env is not set at all – it will be set internally every time ruby and any other ruby or gem binary is run – with a overhead of about 50ms for each invocation.

To explain in depth what rbenv does here is a quote I was originally going to put in here but I already posted the message on reddit:

There is one big hole in shims approach – it makes all the gem and ruby binaries available in your shell … just not always functional.

Having something installed in one ruby (like haml) will make it shim available in all rubies – just not working.

Shim approach is working against the system – building another abstraction layer not respecting UNIX mechanisms – like PATH search – just fooling your system (and you).

It is not possible to run a shim/ruby without rbenv loaded – it s required to to make the environment working as expected – in contrary RVM by default builds environment files which sourced once make your system aware of the exact combination of ruby and gems you want to use.

The environment is set and provided to the ran binary in both cases, only the burden of loading it is shifted, and it means:

  • The loading place makes some difference. In RVM, you can check the state of the environment with ‘rvm info’. For rbenv, there are no changes – so there is nothing to check.
  • For RVM, only the selected ruby/gemset related binaries will be available in the shell. In rbenv, all binaries of all rubies and gems all always available in shell – only they will do nothing when called, it is not possible to check if binary exists in system as the checks always will hit the shim binary and report it as existing.
  • For those concerned about loading and execution time, you can not see the difference. It can be only measured. Anything that occurs at or below 300ms in a shell is imperceptible.

Sam Stephenson provided a list of points that make a difference between the tools, lets consider them:

  1. Need to be loaded into your shell. Instead, rbenv’s shim approach works by adding a directory to your $PATH.
    RVM also does not have to be loaded as a function. It allows operation by loading only the environment file, which is done only once and allows single and fast initialization of the current ruby and gemset. RVM also allows operation as a binary when all it’s functionalities are available (except changing environment other than setting default, which behaves identically to rbenv’s only means of operation).
  2. Override shell commands like cd. That’s dangerous and error-prone.
    Overriding of cd is optional. I searchied for almost 8 hours collectively over the last month to find a project that overrides cd – guess what, I could not find one. There are few shell tricks that allow you to override cd, but as cd override is optional, you can do it in your own function merged with the tricks. As for error prone – I see no reports of errors about the cd function. Once it is done, nothing bad can happen. Additoinally RVM provides a security feature whereby you can view the code to be executed ahead of time upon cd and choose to trust it or not.
  3. Have a configuration file. There’s nothing to configure except which version of Ruby you want to use.
    rbenv, at present, allows setting over 4 shell variables which influence the running process, there is no configuration file that could collect them – they have to be set in your shell rc files – for every shell you use.
  4. Install Ruby. You can build and install Ruby yourself, or use ruby-build to automate the process.
    During it’s life RVM collected lots of knowledge how to manage and install rubies – including patches that make ruby work as expected on different environments. Also supporting fancy things like golf ruby – where original ruby binary is replaced with goruby binary. Why would you not want to capitalize on other’s experience?
  5. Manage gemsets. Bundler is a better way to manage application dependencies. If you have projects that are not yet using Bundler you can install the rbenv-gemset plugin.
    Using gemsets is optional but encouraged as it helps in the separation process, some gems force use of bundler but this does not solve all the separation problems. And the pure existence of rbenv-gemsets proves how useful it is. Even bundler is not impervious to plethora of installed system level gems and their oddities of interaction.
  6. Require changes to Ruby libraries for compatibility. The simplicity of rbenv means as long as it’s in your $PATH, nothing else needs to know about it.
    RVM does not require changes to any gems/libraries although it allows some additions that are meant to make life easier – like per project changing PATH for bundler generated binaries, or allowing set :rvm_ruby_string to specify a ruby version instead of setting PATH like rbenv requires. All those things are optional and not required for proper work neither of RVM or the tool concerned. Finally, separation of gemsets in RVM allows skipping calls to bundle exec – which in case of rbenv will be required (unless using my gem rubygems-bundler gem or other such tricks).
  7. Prompt you with warnings when you switch to a project. Instead of executing arbitrary code, rbenv reads just the version name from each project. There’s nothing to “trust.”
    All the warnings appear only when users create the .rvmrc file manually, if it is created automatically with the –rvmrc flag then a lot less warnings are printed. rbenv actually prints a warning when switching to a project which wants to use ruby that is not installed. Trusting of .rvmrc files can be easily switched to not read them at all or to trust any .rvmrc file.

Opposed to Sam Stephenson points above I would like to give my counterarguments for using rbenv:

  1. Execution of any binary is 50ms slower as compared to binaries run in rvm – so if you are using many calls to ruby – this might get in your way of your performance.
  2. Execution of any binary does not require proper ruby/gem to be available, it will silently fail without any warning if it is not available.
  3. It is not possible to check if ruby or gem binary is available in the system, separate calls to gem, binaries or rbenv are required to find out if it is really available – which adds more work you have to do / worry about. With RVM you set environment – and LINUX conventions allow it to work as expected, with rbenv – the environment is faked with shims, you never know (by linux conventions) what will happen.

So summing up the tools are different but they allow developers to do almost exactly the same thing just with different approaches, knowing the differences could help developers chose the right tool for the right job.

Important point mentioned quite often when RVM and rbenv is compared is the size and complication of RVM. Where rbenv is a new tool, it is relatively small and its internals are less complex. rbenv uses the same approaches as RVM and is more readable if only by smaller code base which is due to the fact it is a far less mature piece of software and has far less experience accommodating different environments and platforms. It has not been extensively tested on most available operating systems. While RVM continues to press forward with new features on a solid software foundation, rbenv will continue to grow and progress but will continue to ride RVM’s coattails. It’s simple to take an existing piece of open source software and apply hindsight to create a more slim, less feature packed and less tested piece of software. We wish to see rbenv grow and expand into a great piece of software that provides a different solution to ruby environment management so both projects may learn from one another.

There is one additional thing that Is available for RVM which you will not find for rbenv – Jewelery Box – the official OS X RVM GUI. As rbenv claims to be minimalistic tool it does not seam to need any GUI – but as popularity of JB shows there is a need for such tool.

In closing, I would like to mention that we know that RVM grow big and could use some refactoring to make it easier to hack on it and to make the code base more readable and maintainable – we are working on that by planning RVM2 as an SM extension – SM is another project from Wayne E. Seguin worth checking and big enough to cover few articles. We hear our users loud and clear and have big plans for the future of RVM.

  1. April 28th, 2012 at 14:53 | #1

    @Wil Moore III
    I have added ruby-version to my list of alternate RVM solutions: https://github.com/wayneeseguin/rvm/blob/master/help/alt.md

    Also please have a look on https://gist.github.com/1912050 – rbfu and RVM already have support for a file .ruby-version to point to per project(dir) ruby version, guess you should support that in program called ‘ruby-version’.

  2. April 28th, 2012 at 10:43 | #2

    There is value in being able to switch between multiple versions of Ruby; however, I do agree that certain problems should be solved upstream and/or through education/documentation rather than trying to build tools that try to be a panacea.

    This is why I felt the need to create and use ruby-version as an alternative: http://wilmoore.github.com/ruby-version

  3. Ayose
    December 21st, 2011 at 03:43 | #3

    > Override shell commands like cd. That’s dangerous and error-prone. Overriding of cd is optional. I searchied for almost 8 hours collectively over the last month to find a project that overrides cd – guess what, I could not find one.

    There is an alternative using the PROMPT_COMMAND. The “How to detect the change directory” in http://codingfulness.tumblr.com/post/11390867983/a-better-console-with-autols can be useful.

  4. December 12th, 2011 at 16:55 | #4

    @Rob Gleeson
    of course rbenv might be useful in some use cases

    i think you missed the point:
    1) is about starting multiple times ruby, it is not disk related, the speed depends on disk only on first read of file, unix systems will cache it and serve later on with speed of RAM
    2) we are fixing all reported errors quite fast, sometimes it is meter of minutes, just report the errors…
    3) it is not about having gems installed in system but about detecting them, rbenv just does not follows some standards like returning error code 127 when something is not found

  5. December 12th, 2011 at 16:32 | #5

    Your counterpoints seem valid, but for 1) I don’t see any scenario where that makes any real impact (specially when on an SSD :)

    For 3), IMHO, having system gems is stupid. rvm/rbenv is always the way to go.

    And 2) is indeed annoying sometimes, but far less annoying than the issues I had with rvm, which I don’t even remember anymore as I switched a long time ago :)

  6. Rob Gleeson
    November 27th, 2011 at 10:05 | #6

    @Michal Papis

    I don’t know if I agree with you – RVM may just use them, but by doing so it can cause unexpected errors in applications like Vim – or any application that is built against one Ruby, but has native extensions loaded from another because of shell environment variables set by RVM.

    ‘rbenv’ does not suffer from this problem at all – because of its design, just like RVM can cause those crashes, because of its design. This isn’t the only problem I’ve had with RVM, but after countless problems, I decided to switch to rbenv, and haven’t looked back since.

    It “just works”, I don’t need to think about it at all, and I don’t need to worry about it causing applications inheriting the same shell crashing because of the unexpected.

    By the way, rails.vim is written entirely in VimL, so that point doesn’t really count, since it is not inheriting any rubygems or anything ruby related like my project does.

  7. November 20th, 2011 at 04:40 | #7

    @Rob Gleeson
    the issue is that for you the environment is unexpected, but for most rails programmers – it is expected to be set exactly with they ruby, especially using plugins like rails.vim where they get proper environment for the application.

    And as for the shell variables configuration, anyone can use them, not only RVM, in any development predating RVM – this was the only way to keep your environments separate, it’s the way ruby environment definition mechanisms were designed, RVM just uses them.

  8. Rob Gleeson
    November 20th, 2011 at 00:11 | #8

    Honestly, I’ve had nothing but trouble with RVM and people using project of mine(https://github.com/robgleeson/hammer.vim)

    Because RVM sets environment variables that change the location of where Ruby looks for gems, a executable such as VIM can be built against Ruby 1.8.7, but try to load gems for Ruby 1.9.1 – mix that with native extensions, and you’ve got segmentation faults.

    RVM doesn’t interpolate well with other programs(such as VIM), because it screws up the environment and sets the unexpected (for users, and other programs).

    The workaround is to define a shell function, ‘vim’, create a subprocess, unset all those environment variables RVM sets, and then execute vim.

    This is just one example of how RVM design can eat into and interrupt the normal flow of other applications.

  9. steve
    November 18th, 2011 at 20:12 | #9

    RVM is problematic. The stupid thing broke all the freaking time. It is a overly complex solution.

    rbenv is much simpler and less error prone. It just works.

    Neither should be required though. The problem should be solved by the ruby team.

    I prefer manually editing my .profile file to include paths to all the rubies I use. No switching like rbenv does and no bloated, buggy messes like RVM.

  10. November 13th, 2011 at 07:18 | #10

    Using `cd` to change rubies and gemsets is a convenient pita. Yes that _seems_ contradictory… overloaded `cd` is nice but if your convention is to use pushd/popd then RVM forces its opinions into your daily life and that is a real pita.

    One thing that no one has addressed: RVM’s API.
    I employ `RVM.use!` and `RVM.gemset_use!` in a few projects. I suspect one can achieve a similar result via Bundler for the gemset change, but a change of rubie is sometimes also of interest…

  11. November 12th, 2011 at 03:39 | #11

    overriding cd is not that bad and can be turned off, and comparing it to shims approach – it seams safer for me, it does not break linux conventions – it uses them to its own advantage

    as for the –help we will changing the behavior in rvm 2.0 which should be coming in few months … and most of the destructive commands now have questions so it should not just implode/empty/delete without asking

  12. November 12th, 2011 at 01:07 | #12

    @Michal Papis

    I appreciate that these bugs get fixed, but “fixing all the bugs that happen because we’re doing something completely mental” does not make the thing you are doing a good idea (I refer specifically to overriding `cd` here, I’m sure other parts of RVM are less mental).

    One issue (easily fixed, but it leaves an impression) was that I passed in –help to some rvm command to see what it did. RVM silently ignored the extra –help argument and destroyed its own installation beyond repair. That’s just bad programming (and terribly bad design to have a program modify its own installation, unless it is a package manager).

  13. November 12th, 2011 at 00:04 | #13

    the bug #123 is most likely fixed (I had similar issues long time ago – and it was fixed already).

    As for the bugs you are mentioning – both tools require reading instructions, not reading/understanding them leads to errors/bugs in both tools, in RVM you can get almost instant support on IRC channel #rvm, so in case you have problems – just ask and most of the problems is solvable within minutes.

  14. November 11th, 2011 at 23:38 | #14

    > I see no reports of errors about the cd function.

    You may not have looked very hard:

    It’s closed, but was never actually fixed – I gave up on RVM and stopped caring. And having only closed issues still doesn’t make it a good idea.

    I found 3 critical issues in RVM on my first day of usage, one of which destroyed RVM itself. RVM is almost amusingly far from being a good idea…

Comments are closed.