What I appreciate about Homebrew is that in years of using it, I have never felt the need to dive deeply into its inner workings. For the most part, it just works. I can access the utilities I need to do my work and reliably keep them updated. Homebrew has its problems for sure, but the tooling has improved immensely over the recent years. So thank you for your work!!!
Also side note, I just recently discovered the brew bundle command's --global flag. It basically let's you use a declarative format globally installed taps, formula, casks, and vscode extensions. I can add the .Brewfile to my dotfiles repo to sync across machines. Though, it's not really what the bundle command is meant for, it sure beats manually copying down and installing the list of formula.
Way too often technical people care more about the pureness of the underlying implementation than they do the end-user experience. I've both worked with and been that person in the past, the person that wants to impose internal implementation limits on the UI/UX. One of the best lessons I've learned is try to make software that behaves how people want it to behave, not necessarily in a way that perfectly jives with how you implemented something on the backend/internally.
I don't know much about the inner workings of homebrew and the best part is I don't have to. MacPorts worked decently enough for me pre-homebrew but it would sometimes break in unexpected ways. Homebrew "just works" in a way that I greatly appreciate.
I've never done a dive into package managers and just used what's been available. So even though homebrew is slower than other package managers, it has also rarely thrown me for a loop.
See the Nix Package Manager[1].
> On the advice of numerous HN threads, I switched from Homebrew to Nix, and gave it a 6 month shot. Nix was great at first: simple, fast, elegant. However, I quickly realized that the simplicity was a facade that even a casual user would eventually be forced to remove. And what you find behind the facade gets really, complex really quickly.
For instance, Google Chrome litters the filesystem and is not easy to clean up manually. Homebrew however can remove all traces by passing the --zap option:
brew uninstall --zap google-chrome
brew info --github google-chrome
I'll give an example:
If I run brew uninstall --zap vmware-fusion and then brew install vmware-fusion VMware Fusion can still pick up various bits from its previous installation (like how my 30-day free trial has expired).
If I drag VMware Fusion into AppCleaner, then run brew uninstall --zap vmware-fusion, then run AppCleaner, when I reinstall VMware Fusion, I can restart the 30-day free trial all over again.
I know this because I have been doing this on an as needed basis for like 5 years now ;).
1. It doesn't work well with multiple users 2. It doesn't build apps using DESTDIR correctly.
Number 2 has been a bigger issue for me. Homebrew configures autotools applications using the full prefix of /usr/local/Cellar/app/version. It then gets installed to that prefix and is symlinked to /usr/local.
The problem here, is apps built like this look for their data in their prefix path (/usr/local/Cellar/app/version/usr/share/data/) rather than /usr/local/data. This ends up breaking things.
For example, I was working on porting a gtk app to mac os, and needed to build gobject bindings. Normally, glib would be built with a prefix of /usr/local, so it'd look for all gobject bindings in /usr/local/share/gir-1.0/. But since glib is being build with a prefix of /usr/local/Cellar/glib/2.40.0, it is expecting all gobject bindings in /usr/local/Cellar/glib/2.40.0/usr/share/gir-1.0/.
But, when I build libchamplain, it installs its gobject file in /usr/local/Cellar/libchamplain/1.0.1/usr/share/gir-1.0/.
Now, everything gets symlinked to /usr/local/share/gir-1.0/, so it looks like it would work, right? Except, gobject was built with the full prefix, so it _only_ looks in /usr/local/Cellar/glib/2.40.0/usr/share/gir-1.0/ for gobject files. This means it doesn't find libchamplain or any other libraries.
The correct way to do this, is to run configure with the destination prefix (/usr/local/), then do an install using DESTIDR: make install DESTDIR=/usr/local/Cellar/glib/2.40.0/. Then you can symlink to /usr/local/.
Homebrew is a great project and has been an incredible help for me.
I am perfectly fine with macOS's UNIX™, out of the box experience.
This is what I was talking about about HN sentiment, though: for some reason you "don't care" enough to click through to the comments on a "Homebrew is Awesome" post and feel the need to tell everyone that you don't care. That's a different experience of "don't care" than I have and I find it intriguing.
https://developer.apple.com/xcode/
https://www.oracle.com/java/technologies/downloads
https://maven.apache.org/download.cgi
https://www.eclipse.org/downloads/
https://dotnet.microsoft.com/en-us/download
https://code.visualstudio.com/
https://visualstudio.microsoft.com/vs/mac/
And I am pretty much done.
For example I have a mono repository which contain Makefile and can produce one or six different executable tools. Four of these six tools are CLI utilities but the other three should work as a service. The problem I have encountered is the lack of documentation or an example of how to write auto-tests for daemons and for utilities in one formula because some of them require a working database from another Formula or in the root of the system. That is, it is very difficult to write such auto-tests, which would check workability, and really it was possible to run them when building the formula.
Yes, the workaround is to make own repository with Homebrew Tap but better to have it in main repository when users could setup software without any additional action.
I'm really not convinced that Ruby syntax is what makes the Homebrew formula DSL non-trivial. I've written enough YAML for k8s stuff that it seems like the language is rarely the cause of misunderstanding.
But If I know I am going to install multiple versions of a program ahead of time, I use asdf-vm instead
(I don’t know why Intel Macs still use /usr/local.) In any case, it’s possible to choose a custom installation location, even on Intel Macs if you prefer.
https://docs.brew.sh/Installation
Further discussion on the decision:
Nothing stopping you from having this owned by a system account, it's just not a path we recommend because it's not the best fit for most of our users.
So you can, but apparently you shouldn't.
There are tools to rewrite links in binaries, but they only work until you get a program calling dlopen or equivalent