Falling white dice

image by Riho Kroll

Read the .ruby-version into your Gemfile

Previously I recommended using a loose version ruby version constraint in your Gemfile. This is still a valuable technique, but here’s another useful variation that’s works well for most of us, most of the time.

Hat tip to Emma for the this one-liner.

Ruby version managers (such as chruby) ensure an application uses a specific version of Ruby by looking for a .ruby-version file in the root directory of each app.

The file specifies the required version of Ruby for the application and the manager automatically switches the environment to use the specified version.

The version can also be specified in your Gemfile using bundler, which is more often used to define the version of Ruby to use in a deployed application.

Instead of…

…specifying your exact ruby version in two places and potentially generating conflicts:

# Gemfile
ruby "2.7.2"
# .ruby-version

This results in an error, as bundler checks the current version of Ruby specified in the Gemfile.

Your Ruby version is 3.0.0, but your Gemfile specified 2.7.2


…the fact that the Gemfile is simply another Ruby file:

# Gemfile
ruby File.read(".ruby-version").strip
# .ruby-version


This means that when you upgrade Ruby you only need to update in one place: the .ruby-version file.

Most of us, most of the time, are happy to specify a version of Ruby for all environments and this is a cool micro-improvement that reminds us that the Gemfile is just another ruby script!

Why not?

There are still services where the availability of new Ruby versions are delayed so the prevous loose ruby version technique might be a better fit for your project.

Last updated on January 11th, 2021 by @andycroll

An email newsletter, with one Ruby/Rails technique delivered with a ‘why?’ and a ‘how?’ every two weeks. It’s deliberately brief, focussed & opinionated.