A Tale of Two Rubies, Part II
Managing Rubies with Rbenv
In my previous article A Tale of Two Rubies, Part I: Managing Rubies with RVM, I covered how to manage ruby versions with RVM, and this is the second part covering Rbenv…
Overview
Rbenv manages ruby versions and corresponding gem environment for that version of ruby. It does this using shims, where shim executable scripts are in the front of your search path.
One your path is configured to use rbenv shims, ruby commands like gem, irb, rake, will run from the appropriate ruby environment that you have configured. After installing gems that have commands, like rails or bundle, you will need to run rbenv rehash to create a new shim for those commands.
If the current ruby environment does not have the gem previously installed, then the shim will inform the user that the command is not available, and what other ruby environments contain the command.
Gemsets
Rbenv doesn’t manage segregated groups of gems with gemsets, as this is considered redundant to bundler which handles segregating gems.
If you need lock in particular versions of commands, you can use bundler’s binstubs facility. If you still absolutely require gemsets, there is a rbenv-gemset plugin for that, but this is not recommended.
The Tutorial
We’ll use to pretend web projects with different ruby versions:
- Project Fearless – Rails 5, Ruby 2.4
- Project Empower – Sinatra, Ruby 2.3
Installing RBEnv
This is the process you can use to install Rbenv on Ubuntu Trusty.
Rubies and Gems
After installation, we can easily switch between ruby versions for the current user. This is how we can install different ruby environments:
The rbenv rehash is only needed for new commands from gems that were installed, once the shim is created, you won’t have to do this again until you install a new gem that comes with a command.
Project Fearless
This is a pretend web project using a recent version of Ruby on Rails 5 on Ruby 2.4.
The previous version of the project used ruby 2.3.6 and rails 4.2. In a real project, the .ruby-version would be updated to reflect current ruby used in the project.
Project Empower
This is a pretend web microservice project using earlier version of Sinatra 1.4 running on Ruby 2.3
Testing Project Rubies
In the projects, we can lock the ruby version so that when we switch into the directory, this ruby version is selected over our global version. This was done with the .ruby-version.
With the above projects, you can see how switching into one of the directories can change the ruby version.
$ cd ${HOME}/projects$ rbenv global 2.3.6
$ ruby -v
ruby 2.3.6p384 (2017-12-14 revision 61254) [x86_64-linux]
$ gem env home
/home/vagrant/.rbenv/versions/2.3.6/lib/ruby/gems/2.3.0$ cd fearless
$ ruby -v
ruby 2.4.3p205 (2017-12-14 revision 61247) [x86_64-linux]
$ gem env home
/home/vagrant/.rbenv/versions/2.4.3/lib/ruby/gems/2.4.0
Conclusion
I hope this series was useful. I wanted to avoid getting to any debate about which method is best, but rather demonstrate both environments and let you come to your own conclusion about which best fits your environment.
