Skip to content

Remove Gem.try_activate usage #1103

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

deivid-rodriguez
Copy link

This is not meant to be merged as is, just opening it mainly as a question. I read the code and I could not understand the purpose of Gem.try_activate here.

The only usage I know of Gem.try_activate is internal to RubyGems. It's part of its custom require implementation. When standard require fails, RubyGems tries to activate a gem including the given path. That way it is added to the $LOAD_PATH and require can succeed when retried a second time.

In this case, it seems to try to activate some potential gem including IRB localizations. However, that gem is never subsequently required so in particular I'm not sure what the redo is for, and not sure either if using Gem.try_activate is necessary at all.

Even if it was necessary, it should be probably guarded by defined?(Bundler::Setup) or something like that, because I don't think Gem.try_activate makes sense in a bundler/setup context, since bundler/setup eliminates RubyGems discovery mechanism and instead sets up a fixed $LOAD_PATH with the gems in your Gemfile. So, technically, if using some localization gem, you should add it to your Gemfile.

For what it's worth, I found this while looking into this Bundler issue: rubygems/rubygems#8754.

@deivid-rodriguez deivid-rodriguez force-pushed the remove-gem-try-activate-usage branch from e1d3644 to b5952ab Compare June 16, 2025 10:18
@deivid-rodriguez
Copy link
Author

Something I've also noticed is that the only internal usage of Locale#find does not pass a second argument to it, so paths is actually the $LOAD_PATH. That means that the paths searched have already been activated ("activating" a gem essentially means putting it in the $LOAD_PATH), so that supports the idea that Gem.try_activate should be unnecessary.

@deivid-rodriguez
Copy link
Author

I merged a workaround in Bundler, so the warnings triggered by this Gem.try_activate usage will no longer show up in newer versions of Bundler. That said, I still think it'd be good to get rid of this if we confirm it's unnecessary.

@deivid-rodriguez
Copy link
Author

There's actually a second issue reported to us due to this, we may choose to also workaround that on our side, but just letting you know. It's rubygems/rubygems#7545.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant