[ruby-core:104022] [Ruby master Feature#17883] Load bundler/setup earlier to make `bundle exec ruby -r` respect Gemfile

Issue #17883 has been updated by deivid (David Rodr刕uez).


In my opinion, all approaches not involving fixing `-r` priority feel hacky.

The `BUNDLE_BIN_PATH` environment variable is something I had considered to remove in the future since it's only used for monkeypatching rubygems helpers to select the proper bundler version, and that's something that should just work without it. So I would prefer any approach that doesn't use this variable. To be honest, since this is about fixing the priority of `bundler/setup` inside `RUBYOPT`, explicitly detecting `bundler/setup` inside RUBYOPT feels more explicit and less hacky to me, even if we fix this in rubygems require.

I guess since bundler already has this feature we have to fix this edge case, but I tend to believe this feature should have never existed in the first place. Over the years we have received many issues where bundler putting `-rbundler/setup` in RUBYOPT and forcing all future ruby processes to use `bundler` as well leads to unexpected hard to debug issues. And it's also the reason why user scripts and rake tasks out there are full of `Bundler.with_original_env` blocks before shelling out. The way I see it, people should choose explicitly whether or not to use bundler in their subprocesses by using or not using `bundle exec` to invoke them. Anyways, I don't think that's something that can be changed now, but I wanted to mention it. 

----------------------------------------
Feature #17883: Load bundler/setup earlier to make `bundle exec ruby -r` respect Gemfile
https://bugs.ruby-lang.org/issues/17883#change-92160

* Author: mame (Yusuke Endoh)
* Status: Open
* Priority: Normal
----------------------------------------
To reproduce the issue, prepare a Gemfile and run `bundle install --path=vendor/bundle`.

```
$ cat Gemfile
source "https://rubygems.org"
gem "activesupport"

$ bundle install --path=vendor/bundle
```

`Kernel#require` respects the Gemfile correctly.

```
$ bundle exec ruby -e 'require "active_support"'
```

However, `bundle exec ruby -ractive_support -e ''` does not.

```
$ bundle exec ruby -ractive_support -e ''
<internal:/home/mame/work/ruby/local/lib/ruby/3.1.0/rubygems/core_ext/kernel_require.rb>:85:in `require': cannot load such file -- active_support (LoadError)
        from <internal:/home/mame/work/ruby/local/lib/ruby/3.1.0/rubygems/core_ext/kernel_require.rb>:85:in `require'
```

We can work around the issue by explicitly passing `-rbundler/setup` before `-ractive_support`, but this is very confusing to me. The same issue was discussed in StackOverflow: https://stackoverflow.com/questions/59623068/correct-way-to-combine-bundle-exec-and-ruby-r

---

Here is my analysis. `bundle exec` sets `RUBYOPT=-rbundler/setup` which replaces `Kernel#require` with bundler's own definition. `-e 'require "active_support"'` correctly triggers bundler's definition. However, `-ractive_support` is evaluated before `RUBYOPT=-rbundler/setup` is evaluated, so it triggers rubygems' require definition which does not know `vendor/bundle` directory.

This is caused by the interpretation order of `RUBYOPT` and command-line arguments.

```
$ RUBYOPT=-r./a ruby -r./b -e ''
:b
:a
```

For compatibility, I don't think that changing the order is a good idea. IMO, it would be good for ruby interpreter to provide Bundler something special, because Bundler is now bundled with Ruby.

My naive idea is to make the interpreter load `ENV["BUNDLE_BIN_PATH"] + "../../lib/bundler/setup"` before any other `-r` options if `BUNDLE_BIN_PATH` is defined. Or another new dedicated environment variable that `bundle exec` sets may work (for example, `RUBY_BUNDLER_SETUP` or something).

@deivid @nobu What do you think?



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>