To codify both replies to yours as an outsider who watches macOS coworkers struggle: brew is akin to running Arch, where the concept is latest-tagged-release of any given software.
The newest version of X introduces a feature which has a need of Y library (dependency) >= n+1, where n is your already installed version. It just so happens that Y is shared between 3 applications; so if you upgrade Y to satisfy X, you now have to recompile/upgrade (depending on details) A, B and C as well to use the newly updated version of Y.
Arch (and other rolling releases) do/does this every day, it's just that the work is offloaded to upstream packagers. Brew is more "AUR-like" where it's all down downstream on your own system, so you get to deal with the work and churn through the recompiles yourself.
> Brew is more "AUR-like" where it's all down downstream on your own system, so you get to deal with the work and churn through the recompiles yourself.
I don’t see how Homebrew would be similar to AUR.
Unlike AUR contributors, Homebrew maintainers curate the packages, test them, monitor upstream projects for updates, build and upload binary packages and do their best to support users when anything breaks.
Anytime a Homebrew user installs a formula from homebrew-core and the system starts to (re-)compile, almost certainly something is wrong.
It depends on the formula, designs and maintainers of them - we run an internal tap and some items are casks, some are bottles and some are compile as you go. It just depends on what that widget is and does, and in some cases there are tools which are broken on latest-tagged releases and people have to pin older versions or using git HEAD for (some period of time) until the tagged released is fixed upstream. (we're looking at you, sshuttle-who-deprecated-remote-python2-in-v1.0-thru-1.0.4-and-broke-lots-of-workflows-with-jumphosts)
For some time now, in the default configuration, `brew upgrade` is run automatically any time you run `brew install`. You have to set HOMEBREW_NO_AUTO_UPDATE to disable this behavior.
EDIT: whoops, that was incorrect. It's actually `brew update` that is run automatically, which updates Homebrew itself plus all of its formulae. However, I think often the effect can't be similar. If formulae are updated, and the new package you're trying to install shares a dependency with other packages, the dependency will be automatically updated as part of the install process. I'm not sure if this can also trigger an update of an existing leaf package though.
Personally; only issue i tend to have is that when I install X, it breaks Y forcing reinstallation of ~everything. What should be a small install ends up taking 30m of cleanup.
Entirely likely it's user error on my part; but also problem I haven't really had with other 'nix package managers.
The newest version of X introduces a feature which has a need of Y library (dependency) >= n+1, where n is your already installed version. It just so happens that Y is shared between 3 applications; so if you upgrade Y to satisfy X, you now have to recompile/upgrade (depending on details) A, B and C as well to use the newly updated version of Y.
Arch (and other rolling releases) do/does this every day, it's just that the work is offloaded to upstream packagers. Brew is more "AUR-like" where it's all down downstream on your own system, so you get to deal with the work and churn through the recompiles yourself.