Ruby like a Pythonista

As a Python developer, I’m accustomed to using virtualenv with virtualenvwrapper to isolate development. Even inside a Vagrant VM or Docker container, I rely on virtualenv to separate my project dependencies from the packages supplied by the system.

Occasionally I find myself working in Ruby, and I’d like to isolate my development there too. There are a couple of worthy options, namely RVM and rbenv. Similarly to virtualenv, these tools create a project-specific directory for installing gems, and then set some environment variables such as GEM_HOME and PATH to use that directory.

If I were working in Ruby more frequently, I’d embrace one or both of those tools. But with virtualenv already in hand, I wondered if there would be a way to piggyback Ruby isolation on my existing toolset. It turns out it’s not hard at all⁠—at least if you’re using virtualenvwrapper, which provides some extra hooks for when you’re activating and deactivating the virtualenv.

To use virtualenvwrapper with Ruby, first put the following in ~/.virtualenvs/postactivate. This will cause these environment variables to be set whenever you do a workon.

# postactivate: this hook is run after every virtualenv is activated.


Second, put the following in ~/.virtualenvs/predeactivate. This will clean up the environment when you do a deactivate.

# predeactivate: this hook is run before every virtualenv is deactivated.

if [[ -n $DEACTIVATE_GEM_HOME ]]; then
    unset GEM_HOME

You don’t need to clean up PATH because virtualenvwrapper already does that in the default postdeactivate hook.

With these hooks in place, you can work on Ruby projects in isolation using the same (Python-based) virtualenv tools that you’re already familiar with. For example:

# Clone a popular ruby project
git clone
cd jekyll-pants

# Make the virtualenv, implicitly runs workon and postactivate
mkvirtualenv jekyll-pants

# Install the dependencies from the Gemfile
bundle install

# Run the tests
bundle exec rspec

The caveat to this approach is that you’ll only have one version of Ruby available⁠—whatever is installed on your system. If you need to work with a different version⁠—or multiple versions⁠—then you’ll want to try RVM, or rbenv with its ruby-build plugin.

So far, though, this setup is working well for me, and I just rely on Travis-CI to test the outlying Ruby versions when I push to Github.

comments powered by Disqus