From: "vo.x (Vit Ondruch)" <noreply@...>
Date: 2022-10-28T18:12:10+00:00
Subject: [ruby-core:110540] [Ruby master Feature#19089] Load bundler/setup in gem_prelude.rb when "bundle exec" is used

Issue #19089 has been updated by vo.x (Vit Ondruch).


jeremyevans0 (Jeremy Evans) wrote in #note-6:
> vo.x (Vit Ondruch) wrote in #note-2:
> > From that POV, it would be much better if it was possible to disable did_you_mean autoloading.
> 
> That's already possible via `--disable-did_you_mean`

Ah, right. I have not realized this. Thx for pointing this out.


Eregon (Benoit Daloze) wrote in #note-8:

I completely agree with your assertions. While I appreciate that Ruby wants to improve the development experience, I think that all these gems should not be used for runtime and from that POV, the defaults are wrong. To the extreme, enabling did_you_mean for production (which is the majority of Ruby runs, right?) is like executing the application test suite before each run.

----------------------------------------
Feature #19089: Load bundler/setup in gem_prelude.rb when "bundle exec" is used
https://bugs.ruby-lang.org/issues/19089#change-99866

* 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: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>