If you're on macOS, you can do a small piece of this natively with AppleScript (or anything that can send apple events) in Chrome or Safari -- namely, you can iterate through windows or tabs, view their source code, and execute arbitrary javascript you pass (there's a one time security option you have to accept). This can be handy for quick automations if you don't want to install anything.

(Background: I have RSI, so I've been developing some integrations between applications and Talon Voice (https://talonvoice.com/). AppleScript ends up being surprisingly valuable/fast/reliable for applications that support it. I also built an integration with iTerm2's Python API before noticing that everything I was trying to do was already supported by its AppleScript dictionary, and was faster. In Google Chrome, the "iterate through tabs and execute javascript in them" is very useful for automating Google Meet muting/unmuting.)

Nothing against this excellent project though; I'm a big fan of Omar's Twitter! And I suspect most here will appreciate the easier scriptability of the filesystem approach than dealing with the atrocious syntax of AppleScript.

It was explained to me when I lived in Japan, that while there are many Japanese media companies that exist independently in Japan, they all have to go to one central government body to renew their licenses to exist. They get some leeway but it's it's not much

You shouldn't use Brew to obtain dependencies. This is how you end up with people complaining about a brew upgrade replacing the version of Postgres their project depends on.

You probably shouldn't be using dpkg or rpm for that, either, unless your CI and deployment targets are running the exact same version of Linux that you are, and even then—there are usually cleaner and more cross-platform/distro ways to do it, especially if you need to easily be able to build or run older versions of your own software (say, for debugging, for git-bisecting, whatever). I continue to wonder how TF people have been using typical Linux package managers, that they end up footgunning themselves with brew. "Incorrectly", I suspect is the answer, more often than not.

Where it excels is installing the tools that you use, that aren't dependencies of projects, but things you use to do your work.

Get your hammer from Brew. Get your lumber from... uh, the proverbial lumber yard, I suppose. Docker, environment-isolated language-specific package managers, vendored-in libs, that kind of thing.

I don't install project deps with Brew (it's a bad idea, but, again, so is doing that with dpkg or rpm or whatever directly on your local OS, a lot of the time) but I do install: wget, emacs, vscode, any non-Safari browsers I want, various xvm-type programs (nvm, pyenv, that stuff), spectacle, macdown, Slack, irssi, and so on.