bundler 2.2.10 installs wrong gem versions

[beanieboi]

Describe the problem as clearly as you can

bundle install is installing wrong gem versions

Post steps to reproduce the problem

$ bundler --version
Bundler version 2.2.10

$ git diff Gemfile.lock

$ bundle config path vendor/bundle

$ bundle install
...install log...

$ git diff Gemfile.lock
diff --git a/Gemfile.lock b/Gemfile.lock
index 91be76b3f7..7781d8a220 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -13,19 +13,34 @@ GIT
       multi_json (~> 1.0)
 
+GEM
+  remote: https://rubygems.org/
+  specs:
+    activemodel (6.1.2.1)
+      activesupport (= 6.1.2.1)
+    activerecord (6.1.2.1)
+      activemodel (= 6.1.2.1)
+      activesupport (= 6.1.2.1)
+    activesupport (6.1.2.1)
       concurrent-ruby (~> 1.0, >= 1.0.2)
-      i18n (>= 0.7, < 2)
-      minitest (~> 5.1)
-      tzinfo (~> 1.1)
-      zeitwerk (~> 2.2, >= 2.2.2)
+      i18n (>= 1.6, < 2)
+      minitest (>= 5.1)
+      tzinfo (~> 2.0)
+      zeitwerk (~> 2.3)
     addressable (2.7.0)
       public_suffix (>= 2.0.2, < 5.0)
... more changes...

What were you expecting to happen?

bundle install should not modify Gemfile.lock
bundle install should install dependencies specified in Gemfile.lock

What actually happened?

bundle install updates gems.

This behaviour is not happening with 2.2.9

[deivid-rodriguez]

Thanks for reporting this. Can you share a reproducible example?

[deivid-rodriguez]

I think I can repro, but I still appreciate an example.

[beanieboi]

Gemfile:

# frozen_string_literal: true

source 'https://rubygems.org'

ruby '2.7.2'

gem 'activesupport'

source "https://USER:PASSWORD@enterprise.contribsys.com/" do
  gem "sidekiq-pro"
end

Gemfile.lock

GEM
  remote: https://rubygems.org/
  remote: https://USER:PASSWORD@enterprise.contribsys.com/
  specs:
    activesupport (6.0.3.4)
      concurrent-ruby (~> 1.0, >= 1.0.2)
      i18n (>= 0.7, < 2)
      minitest (~> 5.1)
      tzinfo (~> 1.1)
      zeitwerk (~> 2.2, >= 2.2.2)
    concurrent-ruby (1.1.8)
    connection_pool (2.2.3)
    i18n (1.8.9)
      concurrent-ruby (~> 1.0)
    minitest (5.14.3)
    rack (2.2.3)
    redis (4.2.5)
    sidekiq (6.1.3)
      connection_pool (>= 2.2.2)
      rack (~> 2.0)
      redis (>= 4.2.0)
    sidekiq-pro (5.2.1)
      connection_pool (>= 2.2.3)
      sidekiq (>= 6.1.0)
    thread_safe (0.3.6)
    tzinfo (1.2.9)
      thread_safe (~> 0.1)
    zeitwerk (2.4.2)

PLATFORMS
  x86_64-darwin-19

DEPENDENCIES
  activesupport
  sidekiq-pro!

RUBY VERSION
   ruby 2.7.2p137

BUNDLED WITH
   2.2.8

with bundler 2.2.10 run:
$ bundle config path vendor/bundle
$ bundle install

after that the Gemfile.lock looks like this:

GEM
  remote: https://USER:PASSWORD@enterprise.contribsys.com/
  specs:
    sidekiq-pro (5.2.1)
      connection_pool (>= 2.2.3)
      sidekiq (>= 6.1.0)

GEM
  remote: https://rubygems.org/
  specs:
    activesupport (6.1.2.1)
      concurrent-ruby (~> 1.0, >= 1.0.2)
      i18n (>= 1.6, < 2)
      minitest (>= 5.1)
      tzinfo (~> 2.0)
      zeitwerk (~> 2.3)
    concurrent-ruby (1.1.8)
    connection_pool (2.2.3)
    i18n (1.8.9)
      concurrent-ruby (~> 1.0)
    minitest (5.14.3)
    rack (2.2.3)
    redis (4.2.5)
    sidekiq (6.1.3)
      connection_pool (>= 2.2.2)
      rack (~> 2.0)
      redis (>= 4.2.0)
    tzinfo (2.0.4)
      concurrent-ruby (~> 1.0)
    zeitwerk (2.4.2)

PLATFORMS
  x86_64-darwin-19

DEPENDENCIES
  activesupport
  sidekiq-pro!

RUBY VERSION
   ruby 2.7.2p137

BUNDLED WITH
   2.2.10

diff for better visibility

diff --git a/Gemfile.lock b/Gemfile.lock
index 11c6d9f..7075be4 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -1,13 +1,19 @@
 GEM
-  remote: https://rubygems.org/
   remote: https://USER:PASSWORD@enterprise.contribsys.com/
   specs:
-    activesupport (6.0.3.4)
+    sidekiq-pro (5.2.1)
+      connection_pool (>= 2.2.3)
+      sidekiq (>= 6.1.0)
+
+GEM
+  remote: https://rubygems.org/
+  specs:
+    activesupport (6.1.2.1)
       concurrent-ruby (~> 1.0, >= 1.0.2)
-      i18n (>= 0.7, < 2)
-      minitest (~> 5.1)
-      tzinfo (~> 1.1)
-      zeitwerk (~> 2.2, >= 2.2.2)
+      i18n (>= 1.6, < 2)
+      minitest (>= 5.1)
+      tzinfo (~> 2.0)
+      zeitwerk (~> 2.3)
     concurrent-ruby (1.1.8)
     connection_pool (2.2.3)
     i18n (1.8.9)
@@ -19,12 +25,8 @@ GEM
       connection_pool (>= 2.2.2)
       rack (~> 2.0)
       redis (>= 4.2.0)
-    sidekiq-pro (5.2.1)
-      connection_pool (>= 2.2.3)
-      sidekiq (>= 6.1.0)
-    thread_safe (0.3.6)
-    tzinfo (1.2.9)
-      thread_safe (~> 0.1)
+    tzinfo (2.0.4)
+      concurrent-ruby (~> 1.0)
     zeitwerk (2.4.2)
 
 PLATFORMS
@@ -38,4 +40,4 @@ RUBY VERSION
    ruby 2.7.2p137
 
 BUNDLED WITH
-   2.2.8
+   2.2.10

[deivid-rodriguez]

For now I reverted the change that caused this issue and released that as 2.2.11. I'll try to reintroduce the secure mode I wanted to introduce without breaking this in future releases.

[krobertson]

Isn't there a test of like it should install the specified versions of gems a test case in bundler? Silently upgrading locked gems can be a serious failure, shouldn't 2.2.10 be yanked?

[deivid-rodriguez]

Isn't there a test of like it should install the specified versions of gems a test case in bundler?

There are a lot of cases that test this, have a look at our test suite if you're interested. We just failed to catch this specific situation unfortunately, hopefully we'll cover it better next time.

Silently upgrading locked gems can be a serious failure, shouldn't 2.2.10 be yanked?

In my experience yanking ruby gems ends up being more harmful that helpful, so I won't be yanking 2.2.10 as I already stated in #4380 (comment).