Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Memoize installed tap loading v2 #16863
Memoize installed tap loading v2 #16863
Changes from all commits
3834ef1
fb8c0d2
d4a2734
e6a453a
0844273
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Check warning on line 60 in Library/Homebrew/cmd/readall.rb
Codecov / codecov/patch
Library/Homebrew/cmd/readall.rb#L60
Check warning on line 149 in Library/Homebrew/cmd/update-report.rb
Codecov / codecov/patch
Library/Homebrew/cmd/update-report.rb#L149
Check warning on line 257 in Library/Homebrew/cmd/update-report.rb
Codecov / codecov/patch
Library/Homebrew/cmd/update-report.rb#L257
Check warning on line 192 in Library/Homebrew/dev-cmd/audit.rb
Codecov / codecov/patch
Library/Homebrew/dev-cmd/audit.rb#L192
Check warning on line 548 in Library/Homebrew/diagnostic.rb
Codecov / codecov/patch
Library/Homebrew/diagnostic.rb#L548
Check warning on line 797 in Library/Homebrew/diagnostic.rb
Codecov / codecov/patch
Library/Homebrew/diagnostic.rb#L797
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's keep these a private implementation detail. I don't really want to have three different ways to do the same thing, e.g.
Tap.select(&:installed?)
vs.Tap.all.select(&:installed?)
vs.Tap.installed
, andTap.all
vs.Tap.to_a
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's preferable to use
Tap.installed
vs.Tap.select(&:installed?)
which is now used widely throughout the codebase if we're already caching that value directly.Tap.all
is currently only used in tests so I think that we can make more of an argument that it can be made private. Keep in mind thatTap.all
andTap.to_a
are not always equivalent.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To me, this is an implementation detail to make
each
faster. In order to have the same performance benefits without exposing a new method, we can do:There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that now that
Tap.each
returns different results depending on whether the API is being used the code becomes a bit more confusing. Why do we need to check that taps are installed or not? That is also an implementation detail.Tap.installed
is simpler to understand when reading the codebase. It was not me intent to add a new method here; that just flowed logically from the two states thatTap.each
can represent within the lifetime of the program. But now that it's here I think we should use it.Is this disagreement a blocker for this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To me, this is a nice helper function that you removed due to your personal preference and is nicer to add back to the way it has been the last ~10 years.
No.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MikeMcQuaid, exactly when did I remove
Tap::installed
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@reitermarkus You made #16710 which required changes like Homebrew/homebrew-bundle#1317.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see what you mean,
Tap::each
was basicallyTap::installed
before. Still, that wasn't a personal preference but necessary to improveTap.each(&:clear_cache)
in tests and fixTap::reverse_tap_migrations_renames
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might make sense to add before spec tags for
:with_api
and:without_api
so that we can avoid this boilerplate and make tests simpler. I also know that specifyingENV["HOMEBREW_NO_INSTALL_FROM_API"] = "1"
is technically unnecessary but it does improve readability.I this makes sense to everyone it can be handled as a follow-up in another PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@apainintheneck makes sense to me! Might be nicer still to have e.g.
with_api
be implicit and onlywithout_api
is needed.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some of the test suite would break in that case I believe. We already automatically set
HOMEBREW_NO_INSTALL_FROM_API
before running tests. I'd rather be explicit even if it adds a small amount redundancy.I guess another option would be to do something like
api: true
andapi: false
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should flip this and unset
HOMEBREW_NO_INSTALL_FROM_API
from the environment (like we do for a bunch of other variables) and addwithout_api
as the non-default case.This is similar to what we do for other environment variables and seems nicer to have tests assume the default environment unless specified otherwise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
HOMEBREW_NO_INSTALL_FROM_API
is currently only set because a bunch of tests would break otherwise, so yes, the goal should be to unset it for tests eventually.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be ideal to not have to set
HOMEBREW_NO_INSTALL_FROM_API
before running tests. Now that I'm looking at the test suite a bit more I realize that we don't have any way of ensuring that we're not making network requests when the:needs_network
flag is not provided. I ran the test suite locally with the API and some of the failures seemed to be related to making unexpected network requests.If we had some way of being reasonably sure that we weren't making unexpected network requests, I'd feel more comfortable unsetting
HOMEBREW_NO_INSTALL_FROM_API
by default.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed.
I think at some point we need to just bite the bullet and switch over. It's mildly concerning to me that the vast majority of our users do not have
HOMEBREW_NO_INSTALL_FROM_API
set but it's what our test suite does by default.Addressing this seems higher priority than ensuring we don't accidentally add network requests as a result (which can be done after).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm worried that this will end up making a bunch of tests flaky because of hard to predict network requests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Flaky tests can be fixed later. I'm more concerned about having tests right now that provide false confidence because they are running in a minority/legacy configuration by default.