Mismatched bundler version - bundler 2, ruby 2.6

user_3839549 0
Viewed 4982

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?

ruby-2.6 bundler ruby-on-rails ruby
5 Answers

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.

user_25319570

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.

user_38395490

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

user_68545360

Have you tried with (ruby 2.6),

gem install bundler -v 1.17.0
user_105225790

It's possible that bundler version is written to binstubs. Regenerate them using bundle binstubs GEM_NAME and it should work.

user_5803460
Related