I recently started working in Ruby for real again, apparently nowadays using rmv is not cool any more, and people seem to like rbenv.

One of the concepts rbenv introduced me to is binstubs.

Reading the wiki we understand that:

Binstubs are wrapper scripts around executables whose purpose is to prepare the environment before dispatching the call to the original executable.

Bin-stubs did you get it? I didn’t at the start, but I’ll blame it to the fact that I’m not a native English speaker.

That’s about it really… Since in the Ruby world executables might need extra stuff to do their job we use a binstub to make sure that the stage is properly set for them to act as expected.

This example, from the guide linked above, makes it clearer:

#!/usr/bin/env ruby
require 'rubygems'

# Prepares the $LOAD_PATH by adding to it lib directories of the gem and
# its dependencies:
gem 'rspec-core'

# Loads the original executable
load Gem.bin_path('rspec-core', 'rspec')

When binstubs come handy

Binstubs come very handy when we want to make sure that all the components of our application run on the same environment.

For example if you have a Rails application you could manually generate a binstub to run the Unicorn server, this will make sure that the version of Unicorn running is using exactly the same Ruby version and Gemset of the Rails application.

Food for thoughts

  • Look back at older projects and revamp them using binstubs. (Who am I kidding, I’m not gonna do it…)
  • Use binstubs in new Ruby projects. (This is more likely!)
  • Look deeper into how rbenv handles binstubs.