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

Refactor Formulary::loader_for. #16623

Merged
merged 19 commits into from Feb 15, 2024

Conversation

reitermarkus
Copy link
Member

@reitermarkus reitermarkus commented Feb 8, 2024

  • Have you followed the guidelines in our Contributing document?
  • Have you checked to ensure there aren't other open Pull Requests for the same change?
  • Have you added an explanation of what your changes do and why you'd like us to include them?
  • Have you written new tests for your changes? Here's an example.
  • Have you successfully run brew style with your changes locally?
  • Have you successfully run brew typecheck with your changes locally?
  • Have you successfully run brew tests with your changes locally?

Use same pattern as in CaskLoader::for.

@reitermarkus reitermarkus force-pushed the formulary-loader-for branch 10 times, most recently from 059ab7f to f6f6312 Compare February 9, 2024 16:59
@apainintheneck
Copy link
Contributor

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.

@reitermarkus
Copy link
Member Author

I will have a look at #16628 to see what causes it.

@reitermarkus reitermarkus force-pushed the formulary-loader-for branch 2 times, most recently from 1e17dee to ebe652f Compare February 10, 2024 14:21
Library/Homebrew/formulary.rb Outdated Show resolved Hide resolved
Library/Homebrew/formulary.rb Outdated Show resolved Hide resolved
Copy link
Member

@MikeMcQuaid MikeMcQuaid left a 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.

Library/Homebrew/formula.rb Show resolved Hide resolved
@Bo98
Copy link
Member

Bo98 commented Feb 12, 2024

(Will do a full review tomorrow)

@reitermarkus reitermarkus force-pushed the formulary-loader-for branch 2 times, most recently from d9e0661 to 170723c Compare February 13, 2024 00:14
Copy link
Member

@Bo98 Bo98 left a 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.

Library/Homebrew/diagnostic.rb Outdated Show resolved Hide resolved
@@ -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)
Copy link
Member

@Bo98 Bo98 Feb 14, 2024

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.

Copy link
Member Author

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.

Copy link
Member

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?

Copy link
Member Author

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.

Library/Homebrew/formulary.rb Show resolved Hide resolved

ref = "#{CoreTap.instance}/#{name}"

name, tap, type = Formulary.tap_formula_name_type(ref, warn: warn)
Copy link
Member

@Bo98 Bo98 Feb 14, 2024

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)?

Copy link
Member Author

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 Show resolved Hide resolved
Library/Homebrew/formulary.rb Outdated Show resolved Hide resolved

def find_formula_from_name(name, tap)
Formulary.find_formula_in_tap(name, tap)
raise TapFormulaAmbiguityError.new(name, loaders.map(&:tap))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.

Copy link
Member Author

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.

Comment on lines 839 to 842
loadable = [
Formulary::FromAPILoader,
Formulary::FromNameLoader,
].any? do |loader_class|
Copy link
Member

@Bo98 Bo98 Feb 14, 2024

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?

Copy link
Member Author

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.

Copy link
Member

@Bo98 Bo98 left a 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!

Copy link
Member

@MikeMcQuaid MikeMcQuaid left a 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!

@reitermarkus reitermarkus merged commit ebd30fb into Homebrew:master Feb 15, 2024
31 checks passed
@reitermarkus reitermarkus deleted the formulary-loader-for branch February 15, 2024 17:09
@github-actions github-actions bot added the outdated PR was locked due to age label Mar 18, 2024
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 18, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
outdated PR was locked due to age
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants