rails command loads the default Bundler 1.17.2 instead of newer installed Bundler 2.1.4

[deepj]

truffleruby 20.1.0-dev-cafc1a20, like ruby 2.6.5, GraalVM CE Native [x86_64-darwin]

git clone https://github.com/chatwoot/chatwoot.git
cd chatwoot
gem install bundler
bundle install
yarn
rails db:migrate

Note: Comment out ruby version in Gemfile before bundle install

TruffleRuby:

You must use Bundler 2 or greater with this lockfile.

$ gem list | grep bundler
bundler (2.1.4, default: 1.17.2)

Ruby 2.7

Model files unchanged.

$ gem list | grep bundler
bundler (2.1.4)

[deepj]

@eregon this can be interesting. This happens after updating TruffleRuby nightly. It's interesting why so many times is nokogiri "loaded" https://gist.github.com/deepj/6b76683ec473607d950473f785032579

[eregon]

It would be more interesting to compare to CRuby 2.6, 2.7 only has Bundler 2 and so many other changes, so it's not really comparable. I'll try to reproduce.

[deepj]

@eregon the situation is identical with 2.6

$ ruby -v
ruby 2.6.5p114 (2019-10-01 revision 67812) [x86_64-darwin18]
$ gem list | grep bundler
bundler (2.1.4, default: 1.17.2)
$ rails db:migrate
Model files unchanged.

[eregon]

I can reproduce with just:

# Gemfile
source 'https://rubygems.org'
gem "path"

# test.rb
require 'bundler/setup'
p Bundler::VERSION

$ gem install bundler
$ bundle install
$ ruby test.rb
You must use Bundler 2 or greater with this lockfile.

I'll need to find out what selects Bundler 2 on MRI in this case, and what happens in the opposite case (if the Gemfile.lock is v1)

[bjfish]

@eregon applying this change should fix this:
rubygems/rubygems@8cbba23

[deepj]

@eregon I can confirm the @bjfish's suggested commit fixes this issue

$ rails c
Loading development environment (Rails 6.0.2.2)
[1] pry(main)> RUBY_DESCRIPTION
=> "truffleruby 20.2.0-dev-b9a3868f, like ruby 2.6.5, GraalVM CE Native [x86_64-darwin]"

[eregon]

@bjfish Nice find! How did you find out this commit was needed?
I confirm it fixes my simple reproducer above, could you make a PR with that fix and add some test to make sure it doesn't regress?

[bjfish]

@eregon A little debugging and I recognized the issue from before I think when rubygems tests were picking up our version of rubygems. So, this may be covered by rubygems tests: https://github.com/rubygems/rubygems/pull/3499/files#diff-254db4345cc461121a9d4dbfd390bc25R385

[bjfish]

@eregon Yes, I'm make a PR with the fix.

[deepj]

@eregon I guess this is fixed

[eregon]

@deepj Right, it seems this issue's example works now. We're adding a test for it and that revealed we need to fix #1956 too, which is in progress. Let's close this issue when the test is merged and passing.

[eregon]

Test added in b9669c4