Skip to content
This repository has been archived by the owner on Apr 14, 2021. It is now read-only.

bundle install does not always sync locked RUBY VERSION with Gemfile specification #4595

Closed
RochesterinNYC opened this issue May 20, 2016 · 2 comments

Comments

@RochesterinNYC
Copy link
Contributor

When you remove the ruby version specified from the Gemfile, bundle install seems to only remove the locked RUBY VERSION from the Gemfile.lock if you have also removed or updated some other gem specification in your Gemfile.

bundle env output:

Environment

    Bundler   1.12.4
    Rubygems  2.5.1
    Ruby      2.3.0p0 (2015-12-25 revision 53290) [x86_64-darwin14]
    GEM_HOME  /Users/pivotal/.rvm/gems/ruby-2.3.0
    GEM_PATH  /Users/pivotal/.rvm/gems/ruby-2.3.0:/Users/pivotal/.rvm/gems/ruby-2.3.0@global
    RVM       1.27.0 (master)
    Git       2.7.3
    rubygems-bundler (1.4.4)

Bundler settings

    gem.coc
      Set for the current user (/Users/pivotal/.bundle/config): "false"
    gem.mit
      Set for the current user (/Users/pivotal/.bundle/config): "true"
    gem.test
      Set for the current user (/Users/pivotal/.bundle/config): "rspec"
    orig_path
      Set via BUNDLE_ORIG_PATH: "/Users/pivotal/.rvm/gems/ruby-2.3.0/bin:/Users/pivotal/.rvm/gems/ruby-2.3.0@global/bin:/Users/pivotal/.rvm/rubies/ruby-2.3.0/bin:/Users/pivotal/.rvm/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/usr/local/share/dotnet/bin:/Users/pivotal/workspace/go/bin:/Users/pivotal/bin:/Applications/Emacs.app/Contents/MacOS/bin:/Users/pivotal/miniconda3/bin"
    orig_gem_path
      Set via BUNDLE_ORIG_GEM_PATH: "/Users/pivotal/.rvm/gems/ruby-2.3.0:/Users/pivotal/.rvm/gems/ruby-2.3.0@global"

Gemfile

    source 'https://rubygems.org'
    ruby "2.3.0"

    gem 'activesupport', '4.2.5'
    gem 'thor'

Gemfile.lock

    GEM
      remote: https://rubygems.org/
      specs:
        activesupport (4.2.5)
          i18n (~> 0.7)
          json (~> 1.7, >= 1.7.7)
          minitest (~> 5.1)
          thread_safe (~> 0.3, >= 0.3.4)
          tzinfo (~> 1.1)
        i18n (0.7.0)
        json (1.8.3)
        minitest (5.9.0)
        thor (0.19.1)
        thread_safe (0.3.5)
        tzinfo (1.2.2)
          thread_safe (~> 0.1)

    PLATFORMS
      ruby

    DEPENDENCIES
      activesupport (= 4.2.5)
      thor

    RUBY VERSION
       ruby 2.3.0p0

    BUNDLED WITH
       1.12.4
  • Remove ruby "2.3.0" line from Gemfile:
source 'https://rubygems.org'
gem 'activesupport', '4.2.5'
gem 'thor'
  • Run bundle install
  • The RUBY VERSION has not been removed in the resulting Gemfile.lock:
GEM
  remote: https://rubygems.org/
  specs:
    activesupport (4.2.5)
      i18n (~> 0.7)
      json (~> 1.7, >= 1.7.7)
      minitest (~> 5.1)
      thread_safe (~> 0.3, >= 0.3.4)
      tzinfo (~> 1.1)
    i18n (0.7.0)
    json (1.8.3)
    minitest (5.9.0)
    thor (0.19.1)
    thread_safe (0.3.5)
    tzinfo (1.2.2)
      thread_safe (~> 0.1)

PLATFORMS
  ruby

DEPENDENCIES
  activesupport (= 4.2.5)
  thor

RUBY VERSION
   ruby 2.3.0p0

BUNDLED WITH
   1.12.4

If instead of just removing the ruby "2.3.0" line from Gemfile, you also remove the gem 'thor' line:

source 'https://rubygems.org'

gem 'activesupport', '4.2.5'

and run bundle install, the resulting Gemfile.lock has the RUBY VERSION removed:

GEM
  remote: https://rubygems.org/
  specs:
    activesupport (4.2.5)
      i18n (~> 0.7)
      json (~> 1.7, >= 1.7.7)
      minitest (~> 5.1)
      thread_safe (~> 0.3, >= 0.3.4)
      tzinfo (~> 1.1)
    i18n (0.7.0)
    json (1.8.3)
    minitest (5.9.0)
    thread_safe (0.3.5)
    tzinfo (1.2.2)
      thread_safe (~> 0.1)

PLATFORMS
  ruby

DEPENDENCIES
  activesupport (= 4.2.5)

BUNDLED WITH
   1.12.4

Reproduction steps by @thewoolleyman

@thewoolleyman
Copy link

Related to this issue - what should the behavior of bundle check be when the ruby version is inconsistent/missing between Gemfile and Gemfile.lock?

It's a common idiom to use bundle check || bundle to short circuit a bundle install run (which can be very slow if you have a bunch of custom remote sources).

Depending on what is done to resolve this issue, if bundle check doesn't enforce the same rules, there could be subsequent failures or inconsistent behavior when using bundle check || bundle.

@thewoolleyman
Copy link

More details:

I think it's a bug in the recent PR for using version operators in Gemfile: #4064

Also there's already an unanswered StackOverflow about the issue: http://stackoverflow.com/questions/36316399/can-i-stop-bundler-from-adding-ruby-version-to-gemfile-lock .

See relevant code here: https://github.com/bundler/bundler/blame/master/lib/bundler/definition.rb#L333 .

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

No branches or pull requests

3 participants