cmd/info: only display keg info if tap matches

[ZhongRuoyu]

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

---

Fixes #19294.

[Bo98]

Seems fine though do we want to handle the case where a tab tap is nil any differently?

[jasonkarns]

Thank you, this resolves the core bug.

I am curious on the overall expected use of homebrew with taps, however. The recent trajectory of homebrew has been to promote more third party taps and less in core. (Removing build options and whatnot such that homebrew core is the 80% happy path, and pushing customization into taps.)

However, the overall use of homebrew does not make taps a "friendly" experience. To wit: brew list lists formulae short names. So a naive process of:

1. brew list
2. find formula
3. brew info <formula-found-in-list-output>

Will not give desired results. brew list lists a formula name that is installed by a tap. Then brew info gives the core formula, not the tap. So on one had brew list says "formula X" is installed. Then brew info X says "Not Installed".

While this PR fixes the core bug (brew-info providing false information), it doesn't improve the overall cohesive use of brew with the ever-growing-presence of 3rd party taps.

[MikeMcQuaid]

I think this should probably be reverted. We don't have many(/any?) other commands where we require fully scoping formulae from taps like this. Instead it feels like we should use the actual formula from the tap if the opt-linked keg is from that tap.

Thoughts?

[jasonkarns]

@MikeMcQuaid I think agree. And that would also improve the cohesiveness issue I commented above. If I have (tap) formula X installed, and I say brew info X, it's most likely the case that I want to see the info for the formula that's actually installed. (I'm looking for installation date; or a reprint of the caveats, or I'm trying to get the URL that I can share with a colleague.)

The downside, then, is that info reports on different formula based on the state of my system. Which seems like it shouldn't be the case. (Info seems like it should be effectively stateless, aside from including installation date details.) I'd also be concerned that switching to the tap formula would make it impossible (?) to see info on the shadowed/core formula? It's rarely my desire to see the core formula info when I have a tap that's shadowing it, but perhaps others have differing needs?

[jrobotham-square]

FYI We're seeing this change break some of our internal tooling that uses brew info under the hood to decide if a tool installed from one of our taps has already been installed. (it's not using the fully qualified tap name when it runs brew info)

We should be able to work around it, but I suspect this is a breaking change that may affect many others.

[jasonkarns]

@jrobotham-square I'm curious how your scripts have been detecting whether the tool that's installed is from core or your tap? (That was the bug this originally attempted to address.)

[Bo98]

For scripts you should be using --json as we don't guarantee stable output in the CLI output, though seems to follow the old behaviour and is thus now incosistent with this new behaviour.

A possible solution here is to:

• Keep this new behaviour for explicit homebrew/core/<name>
• Make brew info <formula> check for installed formulae and use those taps' formulae if it's installed (still loading the latest version from the tap itself for version info rather than the file in the install directory)
• Update --json to match the above

I think that covers all cases?

[jrobotham-square]

I'm curious how your scripts have been detecting whether the tool that's installed is from core or your tap? (That was the bug this originally attempted to address.)

Short answer - I don't think our internal tooling was actually doing this properly and we've probably just been lucky it hasn't bitten us earlier. (it's some tooling our team has inherited)

For scripts you should be using --json as we don't guarantee stable output in the CLI output, though seems to follow the old behaviour and is thus now incosistent with this new behaviour.

Yeah - makes sense - being coupled to the brew info console output isn't great.

FWIW Our script currently has a mix of fully qualified references and short names. I think we've been relying on this bug for it to work up until now.
I think the best path forward for us is to always use the full reference.

[MikeMcQuaid]

• Make brew info <formula> check for installed formulae and use those taps' formulae if it's installed (still loading the latest version from the tap itself for version info rather than the file in the install directory)
• Update --json to match the above

This seems ideal for now. Reverting this until then in #19324 until then.

The recent trajectory of homebrew has been to promote more third party taps and less in core. (Removing build options and whatnot such that homebrew core is the 80% happy path, and pushing customization into taps.)

I disagree with this statement.

While this PR fixes the core bug (brew-info providing false information), it doesn't improve the overall cohesive use of brew with the ever-growing-presence of 3rd party taps.

The only real "fix" here is something we've recommended for a long time but should consider adding more warnings and/or documentation for: using the same names as homebrew/core formulae in taps is simply a bad idea with a lot of rough edges, some of which we can improve, some we cannot.