-
-
Notifications
You must be signed in to change notification settings - Fork 9.7k
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
Refactor Formulary::loader_for
.
#16623
Refactor Formulary::loader_for
.
#16623
Conversation
059ab7f
to
f6f6312
Compare
At a glance, this seems much nicer from a maintainability and readability perspective in. I can't help but think though that we should avoid further changes here until we have some idea why the previous refactor, #16628, caused some problems for users even if it ended up being a problem with a third-party tap. |
I will have a look at #16628 to see what causes it. |
1e17dee
to
ebe652f
Compare
ebe652f
to
f4b9658
Compare
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.
Looks ok so far. Mildly concerned about potential for regressions.
(Will do a full review tomorrow) |
d9e0661
to
170723c
Compare
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.
Apologies for the delay - was a lot to check over.
@@ -111,7 +111,7 @@ class Wrong#{described_class.class_s(formula_name)} < Formula | |||
it "raises an error" do | |||
expect do | |||
described_class.factory(formula_name) | |||
end.to raise_error(FormulaClassUnavailableError) | |||
end.to raise_error(TapFormulaClassUnavailableError) |
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.
Should this really be going through FromTapLoader
? I'm cautious whether this behaviour change is a regression.
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 is loaded from a tap, so the error is correct. I think the only way to get a FormulaClassUnavailableError
now is loading from a bottle, URL or path outside of a tap.
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.
Ok so the change is CoreTap now throws this whereas it previously didn't?
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.
Any tap will throw this when using only the short name to load a formula.
|
||
ref = "#{CoreTap.instance}/#{name}" | ||
|
||
name, tap, type = Formulary.tap_formula_name_type(ref, warn: warn) |
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.
What happens if this hits a migration to Homebrew/cask (i.e. tap.core_tap?
is no longer true)?
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 seems like tap migrations are not handled at all when using the API, so it is never hit. See the early return above, which only checks names/aliases/renames, not tap migrations. This was also the case before this change.
Library/Homebrew/formulary.rb
Outdated
|
||
def find_formula_from_name(name, tap) | ||
Formulary.find_formula_in_tap(name, tap) | ||
raise TapFormulaAmbiguityError.new(name, loaders.map(&:tap)) |
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.
raise TapFormulaAmbiguityError.new(name, loaders.map(&:tap)) | |
if type == :rename | |
raise TapFormulaWithOldnameAmbiguityError.new(???) | |
else | |
raise TapFormulaAmbiguityError.new(name, loaders.map(&:tap)) | |
end |
Or alternatively burn TapFormulaWithOldnameAmbiguityError
entirely, though this PR is already quite large.
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.
Looking at the old logic, it seems like this expects the same old name to occur in multiple taps, rather than a single rename in the default tap conflicting with other taps' formula names. This seems weirdly specific, so I think removing TapFormulaWithOldnameAmbiguityError
makes more sense.
170723c
to
ce60048
Compare
db8bdc6
to
fe1f6c9
Compare
Library/Homebrew/diagnostic.rb
Outdated
loadable = [ | ||
Formulary::FromAPILoader, | ||
Formulary::FromNameLoader, | ||
].any? do |loader_class| |
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.
Does FromDefaultNameLoader
need to be added here now (assuming HOMEBREW_NO_INSTALL_FROM_API=1
) or does this still work as expected?
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 should work without it because of the warn: false
, but doesn't hurt to add it here.
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.
One last question above, but I'm happy otherwise. Thanks!
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.
Seems fine when/if @Bo98 is fine too, thanks!
brew style
with your changes locally?brew typecheck
with your changes locally?brew tests
with your changes locally?Use same pattern as in
CaskLoader::for
.