Skip to content
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

Don't load more specs after the whole set of specs has been setup #4262

Merged
merged 4 commits into from
Jan 11, 2021

Conversation

deivid-rodriguez
Copy link
Member

@deivid-rodriguez deivid-rodriguez commented Jan 8, 2021

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

If bundler is being used, and spec is not included in the bundle, Gem::Specification.find_by_name will still leak outside of the bundle and find globally installed specs.

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

This is a regression of #2711.

The lazy loading provided by that PR when the whole set of @@stubs is not yet set is still interesting, so I kept that but restored the old behaviour of not trying to load anything else once @@stubs have been set.

Fixes #4253.

Make sure the following tasks are checked

We already have specs filtered for a single name. We don't need to group
and merge and full hash, just set that hash entry.
@deivid-rodriguez deivid-rodriguez changed the title Don't load more specs after the whole @@stubs have been set Don't load more specs after the whole set of specs has been setup Jan 11, 2021
@deivid-rodriguez deivid-rodriguez merged commit 7809f5e into master Jan 11, 2021
@deivid-rodriguez deivid-rodriguez deleted the fix_stub_over_loading branch January 11, 2021 09:15
deivid-rodriguez added a commit that referenced this pull request Jan 11, 2021
Don't load more specs after the whole set of specs has been setup

(cherry picked from commit 7809f5e)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Change/bug in behaviour of find_all_by_name in 3.2.0?
2 participants