Thanks for opening a pull request and helping make RubyGems and Bundler better! Someone from the RubyGems team will take a look at your pull request shortly and leave any feedback. Please make sure that your pull request has tests for any changes or added functionality.

We use GitHub Actions to test and make sure your change works functionally and uses acceptable conventions, you can review the current progress of GitHub Actions in the PR status window below.

If you have any questions or concerns that you wish to ask, feel free to leave a comment in this PR or join our #rubygems or #bundler channel on Slack.

For more information about contributing to the RubyGems project feel free to review our CONTRIBUTING guide

Thanks David, appreciate your feedback. Indeed it's been there for 8+ years.
Also made sense to me to just remove the require as it should act pretty much the same for consumers.
Maybe except if someone is checking $LOADED_FEATURES for rubygems/specification which sounds silly.

curious how risky this seems, would this end up in RGs 3.2 or could the change also lend in the 3.1 branch for next release?

Only 3.2.

I mean, do you need us to backport this to 3.1 for jruby?

@kares This sounds like an equivalent issue? Gem::Platform is also autoloaded in lib/rubygems.rb, and explicitly required from rubygems/specification.

This sounds like an equivalent issue? Gem::Platform is also autoloaded in lib/rubygems.rb, and explicitly required from rubygems/specification.

Nice catch, thanks David. Seems like so, let me review all requires and update the PR.
Users likely use Gem::Specification API more so that might be the reason why we've only seen those, so far (from reports).

I mean, do you need us to backport this to 3.1 for jruby?

JRuby's plan was to update RGs to latest 3.1 and patch (for 9.2.12) only if next RGs accepts this PR.
Since users might upgrade RGs not having the patch in next RGs likely makes it not worthy to work-around by patching RGs JRuby ships. And as to why it's not being fixed for real, there's a JRuby load-service rewrite pending and we did not want to spent too much time poking around the current impl, as we might lend a new one in 9.3.

I'm merging this patch and it will be part of rubygems 3.2, that's for sure.

I would also be fine with backporting it to 3.1. We could consider backporting the inverse patch to be 100% sure that nothing breaks, but I think it should be fine as it is. But backporting depends on @hsbt, which is the person who currently releases rubygems.

ℹ️ I can prepare backport patch if needed.

After reading @kares message again, I understand that as long as we include this with both 3.2, and the next 3.1 patch, it should be fine, right? No matter when we actually release those.

I understand that as long as we include this with both 3.2, and the next 3.1 patch, it should be fine, right? No matter when we actually release those.

Yes, that would have been the plan.

I did a review NOT to require autoload-ed dependencies and the changeset has grown.
This could be sold as a startup time improvement as well ... for all Rubies booting RGs.

Let me know what you guys think, does this seem breaking in any ways for the 3.1 backport?

I thought those requires are in place to support requiring only specific files if needed, but for example rubygems/specification is not loadable on its own. I do not see any regression in here.

🤔 Any idea why some files are required explicitly and some are required by autoload? Would it be possible to unify this actually?

Any idea why some files are required explicitly and some are required by autoload?

Maybe required files should only be what's needed for RG's Kernel#reguire to work? Everything else could be 'load on demand'? Unfortunately, this can also affect CI. Having CI/tests require a minimal number of lib files is a good goal, but often impractical...

Yeah, I can only imagine really weird use cases where this would be breaking. I'm fine with merging this as is, and even backporting it.