[ruby-core:104025] [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).


>  Command-line arguments are what a user passed explicitly, so it is natural to me to prioritize them over RUBYOPT.

Yes, that's where we disagree. In my opinion, prioritizing `-r` scripts means letting them run last, so that they can change ruby code in other `-r` scripts loaded before. Just like prioritizing `-I` paths means putting them in the first place in the $LOAD_PATH, or prioritizing `-W` options means processing them last, so that they "win". Anyways, I won't insist further on this.

> BUNDLE_BIN_PATH is just an example. You can use any other name you like.

Hehe, well, I'd like to not add yet another bundler-specific environment variable either if we can avoid it. Anyways, if you have a very strong opinion about using `BUNDLE_BIN_PATH` rather that checking whether `-rbbundler/setup` is included in RUBYOPT, I won't get in the middle of that.

> I agree with this. To speak of extremes, if Bundler had been a built-in feature of Ruby, we would not need bundle exec at all.

> (This is off-topic: Nowadays, many people are using Bundler, so it might be a good time to enable Bundler by default? We can start it with require "bundler/setup" unless ENV["NO_BUNDLER"] :-)

I actually started taking some small steps in that direction. There's already a `RUBYGEMS_GEMDEPS` environment variable to opt into this, but it's not working very well. I'm trying to make it work better here: https://github.com/rubygems/rubygems/pull/4532.

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

* 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>