We've just updated ruby to 2.6 and bundler to 2. Now we're getting:
# bin/rails console
You must use Bundler 2 or greater with this lockfile.
This was previously happening with bundle exec
:
# bundle exec rails console
You must use Bundler 2 or greater with this lockfile.
At that point we were still running 1.17.2 by default:
# gem list bundler
*** LOCAL GEMS ***
bundler (2.0.1, default: 1.17.2)
So we ran gem uninstall bundler --version 1.17.2
and then bundle exec
started working.
But the bin
stubs like bin/rails
are still failing.
How can it be running 1.17.2
when that's been uninstalled?
The diagnose in your answer seems right. But it seems you can activate the latest installed Bundler gem (installed by gem install bundler
) by adding this before the require 'bundler/setup'
line:
Gem::Specification.find_by_name('bundler').activate
More specific version requirements can also be used if needed. For example:
Gem::Specification.find_by_name('bundler', '~> 2.0.1').activate
find_by_name
throws LoadError
derived exception if the gem is not found.
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:
bundle exec
instead. 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.
你试过(ruby 2.6),
gem install bundler -v 1.17.0
If anything this could be an issue with Bundler itself.
try the following steps:
Delete existing Gemfile.lock
Update Rubygems:
gem update --system
Regenerate binstubs version
bundle binstubs bundler
bundle install
bundle install
use bundle exec [command]
to run the things
It's possible that bundler version is written to binstubs . Regenerate them using bundle binstubs GEM_NAME
and it should work.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.