Bypass $LOAD_PATH feature for bundled gems

[hsbt]

What was the end-user or developer problem that led to this PR?

This is PoC and WIP status for https://bugs.ruby-lang.org/issues/19351 and ruby/ruby#7436

I would like to promote current default gems to bundled gems in ruby/ruby repository. After that, the users need to add bundled gems like csv, nkf and others into Gemfile on their application.

The Ruby core team want to reduce additional work with bundled gems from users.

What is your fix for the problem, implemented in this PR?

I introduce bypass feature under the Bundler environment. The users can load bundled gems like csv without gem 'csv' on Gemfile. Additionally, I will warn notice message when user loaded csv library without Gemfile.

Make sure the following tasks are checked

• Describe the problem / feature
• Write tests for features and bug fixes
• Write code to solve the problem
• Make sure you follow the current code style and write meaningful commit messages without tags

[deivid-rodriguez]

I understand wanting to make this transition smooth, thanks for working on this.

After that, the users need to add bundled gems like csv, nkf and others into Gemfile on their application.

In my opinion, this is (part of) the correct solution. Users using csv, and others, directly in their applications, should eventually add csv to their Gemfile. However, if csv is loaded by some gem dependency they are using, then it's that gem that should add csv to their .gemspec file.

Additionally, I will warn notice message when user loaded csv library without Gemfile.

I really like this since I don't like penalizing every Bundler user with having a longer $LOAD_PATH than necessary, just to help a minority of users that may have issues with the new bundled gems no longer being present.

This should be a transitional measure, but the desired long term result should be that bundled gems are treated as usual, and are specified explicitly via Gemfile or gemspec.

However, warning this is tricky, since we don't want to bother end users for issues in their dependencies, which they can't solve directly.

So, I don't have a good solution for warning this.

Another less effective, but easier alternative, would be to let people opt-in to a $LOAD_PATH without bundled gems, and eventually make that the default in the future. Or maybe do it on a per-gem basis: once all supported ruby versions have a gem bundled, stop adding it to the default $LOAD_PATH.

[hsbt]

@deivid-rodriguez Thank you for your feedback. I and @mame, @nobu discussed this. Our plan B is:

• Ruby 3.3: warn for adding bundled gems to Gemfile when user load bundled gems without gem 'foo' in their Gemfile. We can add this warning logic into kernel_require.rb or gem_prelude.rb.
• Ruby 3.4 or later: Raise LoadError same as current behavior and promote bundled gems.

Another less effective, but easier alternative, would be to let people opt-in to a $LOAD_PATH without bundled gems, and eventually make that the default in the future. Or maybe do it on a per-gem basis: once all supported ruby versions have a gem bundled, stop adding it to the default $LOAD_PATH.

Also thanks this idea. I'm considering another idea with this.

[deivid-rodriguez]

Thanks @hsbt.

Ruby 3.3: warn to add bundled gems to Gemfile when user load bundled gems without gem 'foo' in their Gemfile. We can add this warning logic into kernel_require.rb or gem_prelude.rb.

My point is that if user is not using foo directly, why should she add foo to their Gemfile, it makes no sense, Gemfile is for direct dependencies, not indirect dependencies. The solution would be that the author of the gem loading foo adds foo to its gemspec.

So maybe I would instead let people opt-in to not adding bundled gems to $LOAD_PATH through a setting, and eventually stop adding them for everyone once a transitional period has passed (for example, once all supported rubies bundle the gem).

[hsbt]

https://bugs.ruby-lang.org/issues/19351#note-36