Posted 12 days ago. Visible to the public.

Double loading issue with Ruby default gems

Ruby includes many standard gems Archive that are bundled into the Ruby installation. Here is an example for the gem strscan that will be displayed as default:

Copy
gem list strscan *** LOCAL GEMS *** strscan (default: 3.0.1)

It is still possible to have newer version of a gem installed beside the default version:

Copy
gem install strscan Fetching strscan-3.0.3.gem Building native extensions. This could take a while... Successfully installed strscan-3.0.3 1 gem installed
Copy
gem list strscan *** LOCAL GEMS *** strscan (3.0.3, default: 3.0.1)

Therefore is may happen that your Gemfile.lock contains gem versions of default gems that have a newer version than the default version of your Ruby version. This might lead to double loading issues with the an error like below:

Copy
You have already activated strscan 3.0.1, but your Gemfile requires strscan 3.0.3. Since strscan is a default gem, you can either remove your dependency on it or try updating to a newer version of bundler that supports strscan as a default gem. (Gem::LoadError)

This is what happens:

  1. bundle install loads bundler before evaluating the Gemfile.lock
  2. bundler requires the newest version of a gem installed e.g. strscan 3.0.1
  3. Then bundler evaluates the Gemfile.lock and tries to install strscan 3.0.3 and load it
  4. Since strscan 3.0.1 was already loaded by bundler itself, it fails

The error message above recommends to update to a newer version of bundler, but is seems to be a generic error message and there is no fix for strscan in the upstream yet. The main discussions Archive on how to handle standard gems in gemspecs in the future seems not to be finished yet. Until this issue and all the PRs in the gems that depend on standard gems is resolved, I used the following workaround in my Gemfile:

Copy
gem 'strscan', '=3.0.1' # Depend on the standard version of the current Ruby version 3.1.2 (required to be changed once Ruby is upgraded)

Another solution is to install the version in your Gemfile.lock manually before running bundler.

Your development team has a full backlog of feature requests, chores and refactoring coupled with deadlines? We are familiar with that. With our "DevOps as a Service" offering, we support developer teams with infrastructure and operations expertise.

Owner of this card:

Avatar
Emanuel De
Last edit:
7 days ago
by Jakob Scholz
About this deck:
We are makandra and do test-driven, agile Ruby on Rails software development.
License for source code
Posted by Emanuel De to makandra dev
This website uses short-lived cookies to improve usability.
Accept or learn more