image by Riho Kroll
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.
I'm co-chairing RailsConf 2024 in Detroit May 7–9.
Come and join us
Hat tip to Emma for the this one-liner.
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.
…specifying your exact ruby version in two places and potentially generating conflicts:
This results in an error, as bundler checks the current version of Ruby specified in the
Your Ruby version is 3.0.0, but your Gemfile specified 2.7.2
Prior to rubygems version 2.4.19 use…
…the fact that the
Gemfile is simply another Ruby file:
ruby file: ".ruby-version"
You might need to run the following commands to get onto the latest rubygems and bundler for your application.
gem update --system
bundle update --bundler
This means that when you upgrade Ruby you only need to update in one place: the
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!
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.
If you’re using ASDF for multiple tool management (rather than solely a ruby version manager), the
file: argument supports
.tool-versions files too.
Still running UK’s friendliest, Ruby event on Friday 28th June.
Ice cream + Ruby
Last updated on February 7th, 2024 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.