ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: "vo.x (Vit Ondruch)" <noreply@ruby-lang.org>
To: ruby-core@neon.ruby-lang.org
Subject: [ruby-core:110540] [Ruby master Feature#19089] Load bundler/setup in gem_prelude.rb when "bundle exec" is used
Date: Fri, 28 Oct 2022 18:12:10 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-99866.20221028181210.18@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-19089.20221028070347.18@ruby-lang.org

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/

  parent reply	other threads:[~2022-10-28 18:12 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-28  7:03 [ruby-core:110529] [Ruby master Feature#19089] Load bundler/setup in gem_prelude.rb when "bundle exec" is used mame (Yusuke Endoh)
2022-10-28  8:40 ` [ruby-core:110530] " vo.x (Vit Ondruch)
2022-10-28  9:46 ` [ruby-core:110531] " deivid
2022-10-28 11:30 ` [ruby-core:110534] " mame (Yusuke Endoh)
2022-10-28 11:40 ` [ruby-core:110535] " mame (Yusuke Endoh)
2022-10-28 14:50 ` [ruby-core:110536] " jeremyevans0 (Jeremy Evans)
2022-10-28 16:36 ` [ruby-core:110538] " mame (Yusuke Endoh)
2022-10-28 17:20 ` [ruby-core:110539] " Eregon (Benoit Daloze)
2022-10-28 18:12 ` vo.x (Vit Ondruch) [this message]
2022-10-29  1:55 ` [ruby-core:110541] " mame (Yusuke Endoh)
2022-11-02 13:11 ` [ruby-core:110582] " deivid
2022-11-21  3:32 ` [ruby-core:110829] " naruse (Yui NARUSE)
2022-11-21 10:54 ` [ruby-core:110831] " Eregon (Benoit Daloze)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.ruby-lang.org/en/community/mailing-lists/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=redmine.journal-99866.20221028181210.18@ruby-lang.org \
    --to=ruby-core@ruby-lang.org \
    --cc=ruby-core@neon.ruby-lang.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).