Skip to content

bundler 2.2.10 installs wrong gem versions #4383

Closed
#4385
Closed
bundler 2.2.10 installs wrong gem versions#4383
#4385
Labels
Bundler

Description

@beanieboi
beanieboi
opened on 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

Activity

  1. beanieboi
    added
    Bundler
    on Feb 16, 2021
  2. beanieboi
    changed the title [-]bundler 2.2.10[/-] [+]bundler 2.2.10 installs wrong gem versions[/+] on Feb 16, 2021

  3. deivid-rodriguez commented on Feb 16, 2021

    @deivid-rodriguez
    deivid-rodriguez
    on Feb 16, 2021
    Contributor

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

  4. deivid-rodriguez commented on Feb 16, 2021

    @deivid-rodriguez
    deivid-rodriguez
    on Feb 16, 2021
    Contributor

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

  5. beanieboi commented on Feb 16, 2021

    @beanieboi
    beanieboi
    on Feb 16, 2021
    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
  6. deivid-rodriguez
    closed this as completedin #4385on Feb 17, 2021

  7. deivid-rodriguez commented on Feb 17, 2021

    @deivid-rodriguez
    deivid-rodriguez
    on Feb 17, 2021
    Contributor

    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.

  8. krobertson commented on Feb 17, 2021

    @krobertson
    krobertson
    on Feb 17, 2021

    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?

  9. deivid-rodriguez commented on Feb 17, 2021

    @deivid-rodriguez
    deivid-rodriguez
    on Feb 17, 2021
    Contributor

    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

Metadata

Metadata

Assignees

No one assigned

    Labels

    Bundler

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions