From: "mame (Yusuke Endoh)" Date: 2022-10-28T11:30:28+00:00 Subject: [ruby-core:110534] [Ruby master Feature#19089] Load bundler/setup in gem_prelude.rb when "bundle exec" is used Issue #19089 has been updated by mame (Yusuke Endoh). @deivid Thank you for your reply! deivid (David Rodr��guez) wrote in #note-3: > I'm not sure the proposed approach will work when Bundler is installed as a default gem though? Oops, you are right. My current patch does not work with bunlder as a default gem. It would be fixable by parsing `RUBYOPT=-r.../bundler/setup ...` to get the path to `bundler/setup`. It is very ugly, though. Alternatively, if we don't care about the case where multiple versions of bundler are installed, we may just `require "bundler/setup" if ENV["BUNDLE_BIN_PATH"]`. However, > We could set a different variable with the proper path to bundler's lib for this feature I think it is the best. For example, how about this patch? ```diff diff --git a/gem_prelude.rb b/gem_prelude.rb index f382021ca3..8dd1e53c16 100644 --- a/gem_prelude.rb +++ b/gem_prelude.rb @@ -6,6 +6,8 @@ warn "`RubyGems' were not loaded." end if defined?(Gem) +require ENV["BUNDLE_SETUP"] if ENV["BUNDLE_SETUP"] + begin require 'error_highlight' rescue LoadError ``` I am fine with a different environment variable name from `BUNDLE_SETUP`. ---------------------------------------- Feature #19089: Load bundler/setup in gem_prelude.rb when "bundle exec" is used https://bugs.ruby-lang.org/issues/19089#change-99860 * Author: mame (Yusuke Endoh) * Status: Open * Priority: Normal ---------------------------------------- ### Problem Currently, we cannot specify the version of did_you_mean by using Gemfile. For example, Ruby master bundles with did_you_mean 1.6.1 by default: ``` $ ruby -e 'p DidYouMean::VERSION' "1.6.1" ``` Consider that we want to use did_you_mean 1.5.0 with this version of ruby: ``` $ cat Gemfile source "https://rubygems.org" gem "did_you_mean", "= 1.5.0" ``` But the attempt fails: ``` $ bundle exec ruby -e 'p DidYouMean::VERSION' /home/mame/work/ruby/local/lib/ruby/gems/3.2.0+3/gems/bundler-2.3.19/lib/bundler/runtime.rb:308:in `check_for_activated_spec!': You have already activated did_you_mean 1.6.1, but your Gemfile requires did_you_mean 1.5.0. Since did_you_mean is a default gem, you can either remove your dependency on it or try updating to a newer version of bundler that supports did_you_mean as a default gem. (Gem::LoadError) ... ``` This issue is not only with did_you_mean, but also with error_highlight and syntax_suggest which are automatically loaded at the interpreter startup. This example is specifying an older version of did_you_mean, but typically you will want to specify a newer version. Actually, in https://github.com/rails/rails/pull/45818, I wanted to use error_highlight 0.4.0 with Ruby 3.1. (Note that Ruby 3.1 bundles with error_highlight 0.3.0.) The cause of this problem is that `bundle exec` makes the interpreter load `bundler/setup` using `RUBYOPT=-rbundler/setup`, but this load is too late. ### Proposed solution Let's load `bundler/setup` in gem_prelude.rb when `bundle exec` is used. ```diff diff --git a/gem_prelude.rb b/gem_prelude.rb index f382021ca3..825508f571 100644 --- a/gem_prelude.rb +++ b/gem_prelude.rb @@ -6,6 +6,10 @@ warn "`RubyGems' were not loaded." end if defined?(Gem) +if ENV["BUNDLE_BIN_PATH"] + require File.join(File.dirname(ENV["BUNDLE_BIN_PATH"], 2), "lib/bundler/setup") +end + begin require 'error_highlight' rescue LoadError ``` The key is that bundler/setup is loaded immediately after rubygems is loaded, and before error_highlight and did_you_mean are loaded. This patch allows to specify the version of did_you_mean gem by Gemfile: ``` $ cat Gemfile source "https://rubygems.org" gem "did_you_mean", "= 1.5.0" $ bundle exec ruby -e 'p DidYouMean::VERSION' "1.5.0" ``` @deivid What do you think? -- https://bugs.ruby-lang.org/ Unsubscribe: