Ruby equivalent of virtualenv?

No one seems to have mentioned rbenv.

Neither sandbox, RVM, nor rbenv manage the versions of your app’s gem dependencies. The tool for that is bundler.

• use a Gemfile as your application’s dependency declaration
• use bundle install to install explicit versions of these dependencies into an isolated location
• use bundle exec to run your application

I’ll mention the way I do this with Bundler (which I use with RVM – RVM to manage the rubies and a default set of global gems, Bundler to handle project specific gems)

bundler install --binstubs --path vendor

Running this command in the root of a project will install the gems listed from your Gemfile, put the libs in ./vendor, and any executables in ./bin and all requires (if you use bundle console or the Bundler requires) will reference these exes and libs.

If you only need to install gems as non-root, try setting the GEM_HOME environment variable. Then just run gem.

For example:

$ export GEM_HOME=$HOME/local/gems
$ gem install rhc

I recommend direnv. It is an environment switcher for the shell.

Before each prompt it checks for the existence of an “.envrc” file in the current and parent directories. If the file exists (and authorized), it is loaded into a bash sub-shell and all exported variables are then captured by direnv and then made available the current shell.

Here is how to use direnv with ruby-install

+ ruby-install

Add this to the ~/.direnvrc

use_ruby() {
  local ruby_root=$HOME/.rubies/$1
  load_prefix "$ruby_root"
  layout_ruby
}

Install ruby-install (brew install ruby-install) and install a bunch of rubies.

ruby-install ruby 1.9.3
ruby-install ruby 2.0.0
ruby-install ruby 2.2.0

And then make a couple of symlinks for convenience:

ln -s .rubies/1.9 ruby-1.9.3-p*
ln -s .rubies/2.0 ruby-2.0.0
ln -s .rubies/2.2 ruby-2.2.0

And finally in any project’s .envrc:

use ruby 2.0

This will put all gems under the project’s .direnv/ruby directory (makes opening gems easier). bundler will put wrapper binaries in .direnv/bin (no more bundle exec!).

+ rbenv

It’s also possible to use rbenv by adding the use rbenv command in any .envrc file. This will activate rbenv which in turn will put the ruby wrappers in the PATH.

Note that it’s not necessary to install rbenv in the .bashrc or .zshrc for this to work.

+ RVM

Here is the most complicated .envrc that I use on ruby projects:

rvm use 1.8.7
layout ruby
PATH_add .direnv/bundler-bin

rvm is used to select the right ruby version for you

layout commands automatically set some of the usual environment variables. For now only the ruby layout exists. What it does is set the GEM_HOME environment variable and it’s bin directory to your path. Because it depends on the ruby version, make sure to call it after “rvm”. Since each ruby layout directories have their own GEM_HOME, you don’t need to use rvm’s gemsets.

PATH_add prepends and expands the given relative path. In that case, I use this to segregate the bundler binstubs from my own bin scripts with bundle install --binstubs .direnv/bundler-bin

If you want to find out what those commands exactly do, for now: cat direnv stdlib | less

Mineshaft is a project that I’ve been working on for some time and am continuing development work on.

It offers the ability to both create virtual environments akin to how virtualenv works and can also install Ruby globally as well.

Here’s two cents from an experienced Python developer currently learning Ruby. Using rbenv together with its rbenv-gemset plugin is the closest thing to Python Virtual Environments I have found so far.

rbenv is a tool to manage multiple Ruby versions against the same platform. If you are a Python developer you have probably stumbled upon pyenv. Well, they share the very same purpose and, as a matter of fact, pyenv was actually born as a fork of rbenv.

Without entering in to much technical details, rbenv intercepts Ruby commands using SHIM executables injected into your PATH, and determines which Ruby version has been specified by your application, and passes your commands along to the correct Ruby installation.

A Ruby version can be specified for a project in many different ways. One of the most common is to place a .ruby-version file in the project root directory containing the desired version.

However, whenever a version is used to install gems, those will be shared among all the projects using that version.

Here’s where rbenv-gemset plugins comes in handy. In a similar fashion to the .ruby-version file you may initialize a .ruby-gemsets file containing the path of the directory where the gems should be installed for this project (by default a local .gems directory in the project root). Thus isolation between project is achieved.

Here’s an oldie but good article about the topic.