OK, I think we've worked this out.
It turns out that Ruby comes "bundled" with an install of bundler. In our case it's stored in /usr/local/lib/ruby/2.6.0/
next to all the standard library stuff. This version is apparently 1.17.2 of bundler.
This version isn't used if we run bundle exec
because that calls (in our setup) the executable /usr/local/bundle/bin/bundle
- which uses the rubygems install which is 2.0.1.
However, calling bin/rails
or similar binstubs that's not what happens. These bundler-generated stubs have the line:
require_relative '../config/boot'
OK, fine, sounds OK. config/boot.rb
then does:
require 'bundler/setup'
Looks innocuous too. But that doesn't hit the rubygems installs. I guess maybe it can't? Because that's the line that's getting bundler to set up $LOAD_PATH
so that the gems specified in the bundle will actually be used.
So instead of hitting the rubygems install of bundler (2.0.1), it hits the standard library install (1.17.2). Which freaks out because it can see that Gemfile.lock
is too new for it.
This freaking out has apparently only started with v2 of bundler. If it was 1.16 of bundler run on a Gemfile.lock from 1.17.2, it wouldn't care. So having a slightly older standard library bundler presumably hasn't been a problem in the past.
But it is now. So I suppose three possible remediations:
- Don't upgrade bundler to v2 until you're using a Ruby version which comes with bundler v2 in the standard library.
- Do upgrade bundler but don't use the binstubs, use
bundle exec
instead.
- Delete the standard library bundler after install:
rm -rf /usr/local/lib/ruby/2.6.0/bundler*
. That seems to work for us, YMMV obviously though.
(No idea why that last works, if it's required for bundler to be in the standard library for bootstrapping.)
Anyway, hope that helps others save some time in a similar situation.