Decent dependency management please?

[hyiltiz]

The two years old issues #634, #3534 were closed without much discussion, leaving small ground for people who might be interested to start working on a pull request. Two years from that, many core mechanisms in Homebrew changed along with the transition from OSX to macOS. Let's re-open this issue and discuss possible ways to implement a decent dependency management.

A good package management system should take care of orphan packages (that are not currently needed by anything, but was only temporarily needed sometime in the past). Build time dependencies should definitely be cleared when brew cleanup is run (unless installed explicitly by the user), maybe with some additional flag --remove-build-dependencies, and runtime dependencies for packages that are no longer needed and thus removed from the system.

This feature isn't a goal, but a standard (e.g. apt-get, yum, pacman, zypper, pkg and nix to name a few.

[alebcay]

Regardless of where this issue goes in terms of changes being implemented, you may find brew rmtree helpful.

And I would argue that this is not standard behavior in a package manager; when you uninstall a package in apt (what I'm familiar with), it does not remove dependencies that were installed when you installed the package. However, the orphaned dependencies can be removed with apt autoremove. My point here is that this functionality, if implemented, should not be part of the regular brew cleanup process but probably a separate command.

[MikeMcQuaid]

A good package management system should take care of orphan packages (that are not currently needed by anything, but was only temporarily needed sometime in the past)

brew leaves and brew bundle dump can be used to query the packages you've requested the installation of. brew uninstall and brew bundle cleanup can be used to cleanup these packages. Both are documented in man brew.

Build time dependencies should definitely be cleared when brew cleanup is run (unless installed explicitly by the user)

That's not the purpose of brew cleanup and it would be surprising behaviour to change it to start uninstalling packages (particularly once it is run automatically #4760).

This feature isn't a goal, but a standard (e.g. apt-get)

apt-get doesn't automatically remove dependencies; you need to run apt-get autoremove. That makes me pretty dubious about your claims that any of the others will either.

decent dependency management
A good package management system
This feature isn't a goal, but a standard

This wording, intentional or not, is rude about the Homebrew project implying that it is not good, providing decent dependency management or standard features. In addition, you didn't fill out the issue template. Please reconsider your language in future issues and comments on this issue tracker; as-is it's demotivating and rude.

[chdiza]

Build time dependencies should definitely be cleared when brew cleanup is run (unless installed explicitly by the user)

No. Some build-time dependencies will get used again when building something else. E.g., pkg-config. Better to keep them around by default.

[hyiltiz]

@chdiza Common build-time dependencies like pkg-config, fontconfig, cmake etc. does make sense to keep around. In that case, a meta-package (something like build-essentials for Debian) might be useful, so users who frequently build their own software can keep the meta-package, but clean up one-time build-dependencies like qt and gtk, and some project specific stuff like ninja and gradle.

@alebcay brew cleanup should definitely keep doing what it currently does; you might have missed my suggestion specifically for a flag like --remove-build-dependencies. And please do not misrepresent what I said. I said the feature is implemented in apt-get, so you can do it if and when you want to; it doesn't mean it does anything automatically behind the user's back.

@MikeMcQuaid Yes, I agree. Let's stay on topic and discuss technical details. No one is getting paid for arguing or rants. Your suggestion implied there is already a way to implement what I was suggesting. I tried, but it seems something isn't working.

~ $ brew leaves
Error: No available formula with the name "ecj"
~ $ brew info ecj
Error: No available formula with the name "ecj"
==> Searching for a previously deleted formula (in the last month)...
Warning: homebrew/core is shallow clone. To get complete history run:
  git -C "$(brew --repo homebrew/core)" fetch --unshallow
Error: No previously deleted formula found.
~ $ brew bundle dump
==> Tapping homebrew/bundle
Cloning into '/usr/local/Homebrew/Library/Taps/homebrew/homebrew-bundle'...
remote: Counting objects: 70, done.
remote: Compressing objects: 100% (65/65), done.
remote: Total 70 (delta 5), reused 20 (delta 2), pack-reused 0
Unpacking objects: 100% (70/70), done.
Tapped 1 command (153 files, 219.5KB).
~ $ # Would be nice to explicitly tell the user where the output file is stored here, 
~ $ # instead of in the man page

[chdiza]

In that case, a meta-package

The work that would go into a metapackage could just be put into an external command that does what you want. An external command is no harder to type than brew cleanup --some-big-flagname.

[MikeMcQuaid]

Let's stay on topic and discuss technical details.

So long as you are able to avoid being rude: lets. The tone used in messages, however, does matter; it cannot be divorced from technical details.

but clean up one-time build-dependencies like qt and gtk, and some project specific stuff like ninja and gradle.

We're not going to do this. Let's stop discussing it, please.

Error: No available formula with the name "ecj"

This is an issue with your installation unrelated to your feature request here. The command produces an error so it is not behaving as documented.

brew bundle dump

Note you did not run brew bundle cleanup which is required to cleanup those files. Please try that and see if it does what you want it to.

[hyiltiz]

It seems something requires ecj, instead of gcc with java enabled and java virtual machine stuff. I know next to nothing of java so my assumptions may simply not hold. brew bundle cleanup doesn't seem to work either. My setup seems to be healthy, as brew doctor only complains about gs and a library that I used to build stuff, and doesn't seem to be related to anything we are discussing here.

~ $ brew install ecj
Updating Homebrew...
==> Auto-updated Homebrew!
Updated 1 tap (homebrew/core).
==> Updated Formulae
metabase

Error: No available formula with the name "ecj"
==> Searching for a previously deleted formula (in the last month)...
Warning: homebrew/core is shallow clone. To get complete history run:
  git -C "$(brew --repo homebrew/core)" fetch --unshallow

Error: No previously deleted formula found.
==> Searching for similarly named formulae...
Error: No similarly named formulae found.
==> Searching taps...
==> Searching taps on GitHub...
Error: No formulae found in taps.

~ $ brew bundle cleanup
Error: No Brewfile found

~ $ brew doctor
Please note that these warnings are just used to help the Homebrew maintainers
with debugging if you file an issue. If everything you use Homebrew for is
working fine: please don't worry or file an issue; just ignore this. Thanks!

Warning: Putting non-prefixed findutils in your path can cause python builds to fail.

Warning: You have unlinked kegs in your Cellar
Leaving kegs unlinked can lead to build-trouble and cause brews that depend on
those kegs to fail to run properly once built. Run `brew link` on these:
  ghostscript
  suite-sparse

I don't seem to be able to persuade you that this feature is worth considering (now it is virtually in a will not implement status), and am not interested anymore. I guess you'd like to close this issue at this point.

[MikeMcQuaid]

I don't seem to be able to persuade you that this feature is worth considering (now it is virtually in a will not implement status), and am not interested anymore.

It's not that it's not worth considering, it's that it already exists. Check out the https://github.com/homebrew/homebrew-bundle or brew bundle --help information and you may be able to get it working.