Is rubygems_plugin.rb no longer loaded when bundle install is run?

[impostorsguides]

TL;DR

Is it true that there was a time (perhaps, in an earlier version of Bundler) when rubygems_plugin.rb would have been loaded when bundle install was run, and now that's no longer the case?

Background

I'm reading the RBENV codebase, and I came upon its rubygems_plugin.rb file. It includes the following code:

if defined?(Bundler::Installer) && Bundler::Installer.respond_to?(:install) && !Bundler::Installer.respond_to?(:install_without_rbenv_rehash)
  Bundler::Installer.class_eval do
  ...
end

According to the PR that introduced it, the goal of this code is to ensure that RBENV rebuilds its shims only at the end of the bundle install process, as opposed to after each gem installation. This implies that bundle install will run RubyGems plugins.

However, When I add debugger statements to the rubygems_plugin.rb file and run bundle install in a fresh Rails project using a newly-installed Ruby version (v3.1.4), I don't hit my debuggers. This implies the file is not being loaded, after all.

I tried to install the version of Ruby which was active at the time of the original PR (v2.1.2), but it's no longer supported (and in fact, can no longer be installed on my 2023 Macbook).

Are my assumptions somehow faulty? Was there a time (perhaps, in an earlier version of Bundler) when the file would have been loaded, but that's no longer the case?

[impostorsguides]

Upon further research, it looks like the above behavior was introduced in this Bundler PR, specifically the removal of the following line of code from lib/bundler/cli/install.rb:

Gem.load_env_plugins if Gem.respond_to?(:load_env_plugins)

Unless I'm mistaken, it appears that Bundler no longer reads LOAD_PATH and/or RUBYLIB (?) to search for potential RubyGems plugins, meaning RBENV's post-install gem rehashing no longer works.

It seems like there was some discussion in the original PR about calling both Gem.load_plugins and Gem.load_env_plugins, but in the end the decision was made to only call the former, not the latter. Was that intentional? If not, I'd be happy to submit a PR adding the above line of code back to this file as well as update.rb, which I see was also affected.

[impostorsguides]

@hsbt can this be re-opened? I unmarked this as "Answered" because I never got confirmation on whether the above change was intentional, and/or whether the PR I mentioned would be useful.

[indirect]

This pull request seems to deliberately add back load_env_plugins, specifically for rbenv: #3534. Has something else happened to make the rbenv code stop working?

[impostorsguides]

@indirect I'm actually on a new laptop now so I'm unable to see the RubyGems version I was on at the time I reported the issue, or whether it's higher/lower than the version in the PR you linked to, but here's some additional context from the RBENV side.

TL;DR- a bit more technical background on how the issue was discovered, plus a note from the RBENV core team saying they're OK with leaving the functionality as-is. So it looks like we can close out this discussion for now.

[deivid-rodriguez]

Indeed, this should be working so we may have regressed here. I think it's worth looking into this, particularly because the rackup executable has been moved from rack to rackup gem with rack 3, so after upgrading to rack 3, people may need some reshiming for thinks to work flawlessly.

[impostorsguides]

I just re-attempted the steps outlined here, but with rbenv v1.2.0, Ruby v3.2.2 and gem v3.4.10, adding debugger breakpoints before and after if defined?(Bundler::Installer) && inside RBENV's rubygems_plugin.rb file here. This time, I did indeed hit those breakpoints when running bundle install on a new Rails project with a gem added to Gemfile.

It could have been a simple version issue on my end, i.e. perhaps my Bundler version didn't include the PR that @indirect linked to above. Unfortunately, there's no way to verify that at this point since I no longer have access to that laptop. But it seems like the issue is no longer present?

At any rate, happy to answer any questions if it'll help resolve this issue, although to be honest I reported this issue long enough ago that I've lost mental context on much of it.

[deivid-rodriguez]

Ok, let's assume this is working fine then and we have not actually regressed. If someone else sees this, we can reopen this as a bug.