Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bundler 2.2.10 installs wrong gem versions #4383

Closed
beanieboi opened this issue Feb 16, 2021 · 6 comments · Fixed by #4385
Closed

bundler 2.2.10 installs wrong gem versions #4383

beanieboi opened this issue Feb 16, 2021 · 6 comments · Fixed by #4385
Labels

Comments

@beanieboi
Copy link

beanieboi commented Feb 16, 2021

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

@beanieboi beanieboi changed the title bundler 2.2.10 bundler 2.2.10 installs wrong gem versions Feb 16, 2021
@deivid-rodriguez
Copy link
Member

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

@deivid-rodriguez
Copy link
Member

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

@beanieboi
Copy link
Author

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
Copy link
Member

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
Copy link

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
Copy link
Member

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants