-
-
Notifications
You must be signed in to change notification settings - Fork 10.2k
Brew info reports an incorrect formula URL from a tap #19294
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
Comments
PR to fix this (#19295 ) was reverted by #19324 thus this issue exists again. Desired solution described #19295 (comment) Would like to reopen this. |
This is the only thing that should be changed/fixed in this output. Unless I'm mistaken, everything else is correct. We shouldn't require We could consider duplicating/including something the new |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
Not quite. In addition to the
Here is my output from
With such a mix of lines, I can't tell what the expected behavior is supposed to be. But if Really it seems like this command needs to have the expected behavior in the conflicting-formula scenario thought through from scratch? |
For completeness: here is various brew-info output (both abbreviated and fully-qualified formula name, while untapped, tapped-but-not-installed, tapped-and-installed): abbreviated, from core (tap removed)
fully qualified, not installed
fully qualified, installed from tap
abbreviated, installed from tap
|
This isn't actually "from the tap". Homebrew doesn't know or care which tap this is installed from here. It could be annotated with the specific tap name. |
I mean "it's from the tap" in the sense that |
They are not meant to be the same. One ( Formulae are never technically "installed". Kegs are "installed" in a rack. Formulae can have taps, racks cannot. This is because there always has been (and always will be) overlapping namespaces between "short name formulae" and "racks" and not between "full name formulae" or "taps". The keg is named It would not make sense to say "nothing is installed here". Again: this is why shadowing formula names is not the best idea and why we now warn about it. |
Ah, that clarifies a lot! (I didn't have any prior experience with the concept of a "rack" so this distinction helps! appreciate that in the terminology docs) If I'm understanding better, then would any of the following bits of data be more appropriately tied to the versioned keg that's installed?
It seems that the top bits of the info output print from whatever the latest formulae has (so Then there's a section that seems to read from the rack (beginning with "Installed"), which prints the keg path, installation date, and formula path (the latter being "wrong"). From that point, it prints It might just be worth clarifying which sections of the output print from keg (ie, details from the keg that are pinned from what was actually the values at installation time) and which print from that rack (aka, pulling from latest formula found)?
Understood. I'm wondering what homebrew's recommended workflow would look like for a tap that is published with a non-conflicting rack name. It is effectively "complete" and working in the wild for years. And then a new formula is added to core that introduces the conflict. Is it expected that tap owners perpetually monitor and retroactively rename? (Whether the taps even still have active maintainers, notwithstanding.) Or is it recommended that taps preemptively "namespace" their racks with a prefix or something to reduce the chance of future conflicts that are out of their control? (One can't completely prevent a future conflict without some namespace reservation mechanism, of course.) |
Yup, this part of "Installed" is the only thing that seems "wrong" to me.
I guess we don't have an explicit/documented recommendation here.
Yeh, pretty much this, unfortunately.
Given Homebrew's rolling release nature and deprecation process: not having active maintainers often results in broken formulae, unfortunately. I think this is another part the side effects of that. I don't really see any perfect solution to resolve, unfortunately 😭 |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
brew doctor
outputVerification
brew doctor
output" above saysYour system is ready to brew.
and am still able to reproduce my issue.brew update
twice and am still able to reproduce my issue.brew install wget
. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.brew config
outputWhat were you trying to do (and why)?
I was trying to find the url for a formula that i have installed in order to share it with colleagues.
The utility I wanted to share was
git-sync
, but the one I have installed is from a tap, not core. There is a conflicting formula on core titledgit-sync
.What happened (include all command output)?
I ran:
To get the formula URL. But I know this to be not the formula that I have installed. Despite
brew info
reporting that it is installed.I eventually found the tap formula and was able to reproduce the bug whereby brew reports a formula as installed that is decidedly not installed.
What did you expect to happen?
I expected
brew info git-sync
to perhaps include a note that a conflicting formula (from a tap) is already installed. But at the very least, I expectedbrew info git-sync
to tell me that it was not installed because the core formula is indeed not installed. In addition to it incorrectly stating it's installed, it even gives installation date/method that are from the tap's formula, not the core formula.Step-by-step reproduction instructions (by running
brew
commands)The text was updated successfully, but these errors were encountered: