Brew is best for your tools you use directly. Your editor(s), torrent client, curl, your shell. Stuff like that.
Other tools are better for build or project dependencies.
Most Linux package managers are also not ideal for that purpose, incidentally.
Other tools are better for build or project dependencies.
Most Linux package managers are also not ideal for that purpose, incidentally.
I always want the latest version of git or ripgrep, no questions asked. Brew does that well. But for Rust, Node and others where you’re switching between versions, I prefer rustup, nvm etc.
Go is an exception though, I find I never want to go to a previous version of Go so brew is fine.
Which is a reasonable assumption to make, for example, if the language in question is also used by system utilities in a traditional Linux distribution. You really don't want yum invoking the wrong version of python.
For newer languages that change fast, though, we need something different. I don't think "every project brings in its own language runtime and the kitchen sink" is a sustainable situation, either. The dependency graph is crazy enough already.
The problem here is that it's impossible to build a coherent distro if you allow arbitrary mixing of versions, without parallel installability. I don't think it can really be solved in the general case.
Yep, this is the core reason: there needs to be a "system" distribution of Python, Ruby, etc. for packages written in those languages, and that distribution fundamentally needs to prioritize the interests of the package manager over "external" uses. This is particularly painful in the Python world, since using a "system" Python distribution for local development can break the system itself in all kinds of fun and exciting ways (usually beginning with a well-intentioned `sudo pip install ...`).
Homebrew suffers from this like other system package managers do, with the added pain that many macOS users expect Homebrew to do everything (whereas Linux users typically understand that they need `pyenv` or similar). PEP 668[1] helps a bit here by clarifying the responsibilities/expected behavior of system Python distributions, but at the cost of heartburn for some user scenarios (i.e. ones that depend on `pip install -U` and similar).