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
brew deps
output shows inconsistent dependency information between tree and non-tree output
#16032
Comments
Created as a homebrew issue and not a formula issue as this behavior seems more likely to be on the homebrew side. |
I haven't looked into this but I can say that we have different dependency resolution code for the normal and tree versions of the |
I think this is similar to #13717 (see also https://github.com/orgs/Homebrew/discussions/4784) -- there is a discrepancy between dependency information from the tab (i.e., install receipt) and that from the formulae which can be updated after the installation. In this case, |
@ZhongRuoyu Yep, you're right. That's exactly what's happening here. We end up calling brew/Library/Homebrew/formula.rb Lines 2120 to 2122 in f1d345a
|
brew deps
output shows inconsistent dependency information between tree and non-tree output
I think it should always use rather than always skip the tab but: yes, I agree it would be much better (and would fix this bug) to be consistent here. |
I'm hesitant to change this since it's one of the few places where we get a glimpse of what's happening in the tab and for that reason it's occasionally useful for debugging. Ideally we'd store more up-to-date information in the tab but that's a very difficult problem as described in the original issue and I assume that's why nobody picked it up at the time. I'm not sure if users expect this command to reflect installed versions or latest versions of packages in the event that an installed package is on an older version (through pinning or not updating it yet). Right now it seems to default to the installed version which seems reasonable. |
It does seem like |
My own expectations as a user:
It makes sense to me that for certain purposes, especially debugging, that you might want to know exactly what package and version were installed via tracking a receipt for a given install operation. That makes total sense. What doesn't make sense to me is that you would show this type of information as the default for any command, especially for the baseline command I would reach for if I was looking for dependency information. Would it be unreasonable to add a separate, different option to show information from the "install receipt / tab," and show the current dependency information (same as the |
It didn't use to be the default and people complained that it didn't match what's happening on their machine. There's not a single default that everyone will agree on and not find confusing.
We could/should add an option for the opposite: to discard the information from your tap and use only what the formula says. |
@lorentzforces Just to be sure would you be willing to share the install receipt for this package? Something like this should work.
I also wonder what the output of this is?
The command you showed brew/Library/Homebrew/cmd/deps.rb Lines 200 to 203 in 5ec560a
I'm also inclined to open a new issue for the outdated install receipt since it seems like it's still causing unexpected behavior with multiple commands. |
@apainintheneck sure! Output of {
"homebrew_version": "4.0.11-95-gd15f571",
"used_options": [
],
"unused_options": [
],
"built_as_bottle": true,
"poured_from_bottle": true,
"loaded_from_api": true,
"installed_as_dependency": false,
"installed_on_request": true,
"changed_files": [
"share/man/man1/tmux.1"
],
"time": 1680893890,
"source_modified_time": 1654774350,
"compiler": "clang",
"aliases": [
],
"runtime_dependencies": [
{
"full_name": "ca-certificates",
"version": "2023-01-10",
"declared_directly": false
},
{
"full_name": "[email protected]",
"version": "1.1.1t",
"declared_directly": false
},
{
"full_name": "libevent",
"version": "2.1.12",
"declared_directly": true
},
{
"full_name": "ncurses",
"version": "6.4",
"declared_directly": true
},
{
"full_name": "utf8proc",
"version": "2.8.0",
"declared_directly": true
}
],
"source": {
"spec": "stable",
"versions": {
"stable": "3.3a",
"head": null,
"version_scheme": 0
},
"path": "/opt/homebrew/Library/Taps/homebrew/homebrew-core/Formula/tmux.rb",
"tap_git_head": null,
"tap": "homebrew/core"
},
"arch": "arm64",
"built_on": {
"os": "Macintosh",
"os_version": "macOS 13",
"cpu_family": "dunno",
"xcode": "14.2",
"clt": "14.2.0.0.1.1668646533",
"preferred_perl": "5.30"
}
} Output of
@MikeMcQuaid this seems like an odd statement to me; I have a pretty big conceptual gulf between "what is happening on the machine" and "what operations were historically performed on the machine," and to me that first one is much more important in my day-to-day. (I'm also defining "what is happening on the machine" as "what gets run when I run this program," not "what did homebrew do," which may also be different from "typical" usage) That might be naivete on my part - I'm not someone who administrates machines or deployments, just someone who uses Homebrew to install programs for my dev environment on MacOS or Linuxbrew to keep packages outside my standard package manager up to date easily.
This is absolutely reasonable, and I'm 100% happy with such an option. As long as I can keep a specific option in my head that will do what I expect/want every time, that solves all my problems. |
Thanks for the debugging info! After looking at things again, For example, |
yeah that's exactly the hack I have used numerous times myself. |
We have this issue every time there's a OpenSSL migration. Ignoring the But yes it does cause issues when (Though yeah, this is treading towards a separate issue rather than |
Better still may be to make this both an option an a documented environment variable so you can set it once and always do what you want. Another thing worth noted about preferring/deciding between using the tab and recalculating the dependencies: the prior is way quicker. |
There was recently added a paragraph to the command's docs addressing this:
|
I'm debugging something and I'm not sure it is related or not (happy to file a separate issue). What I'm seeing is severe differences between
It seems to me that this is hinting at stale install info possibly causing some of the pain for OP. Please feel free to tell me this is unrelated and to file a separate issue. HOMEBREW_VERSION: 4.1.14-60-g5349b76-dirty (dirty is unrelated... I think I found a bug in |
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)?
When checking to see which of my installed homebrew packages had updates, I noticed that I had both [email protected] and OpenSSL@3 installed. I didn't realize I had two versions, and I wanted to know which packages depended on each respective version, if any. I have found a few unused packages recently in my Homebrew installation, and wanted to clean up packages that weren't being used.
I ran
brew deps --tree --installed
to look at all dependencies, and searched for "[email protected]" in that output.What happened (include all command output)?
On initial check, I did not see "[email protected]" listed anywhere in the command's output.
I narrowed this down and found an inconsistency in
brew deps
output as follows.Output of
brew deps --installed tmux
:Output of
brew deps --tree --installed tmux
:Note the different versions of openssl reported between these two commands.
What did you expect to happen?
I expect the same specific version of a package to be reported as a dependency regardless of which command or command arguments are used to view dependencies.
Step-by-step reproduction instructions (by running
brew
commands)The text was updated successfully, but these errors were encountered: