Homebrew Is Awesome(danthesalmon.com)
danthesalmon.com
Homebrew Is Awesome
https://danthesalmon.com/homebrew-is-awesome/
58 comments
As someone who has been working on Homebrew for 14 years: it’s nice to see something positive about Homebrew on the front-page for a change. Homebrew is far from perfect or the best package manager but it is still surprising to me how much the Hacker News crowd likes to hate on something so ubiquitous with no meaningful corporate backing run by volunteers mostly in their spare time.
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.
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.
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.
I've never understood the homebrew hate. As an end-user I could not give less of a shit about the underlying implementation but instead I care about how it works for me and having used it well over a decade and often using it "blind" ("Hey, I want cli tool XYZ, let's try `brew install XYZ`, nice! That worked perfectly!") I can say it works amazingly well.
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.
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.
Don't let the haters get you down. I appreciate homebrew every day, and I know there are thousands more out there like me. It makes using a Mac so much more fun! I appreciate this because I sometimes have to use Windows, where package installation is... lacking.
I've seen the overal negative sentiment as well. As someone who's been using homebrew since I think 2012, I've enjoyed using it a lot with only some rare issues. So overal it's been a great experience.
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.
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.
> I've never done a dive into package managers and just used what's been available.
See the Nix Package Manager[1].
1. https://checkoway.net/musings/nix/
See the Nix Package Manager[1].
1. https://checkoway.net/musings/nix/
I'm someone who very much loves the concept of Nix and what it is trying to achieve. However, a sibling poster put it well:
> 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.
> 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.
Homebrew is among the top-3 reasons I enjoy developing on Mac. Thanks a lot for your work!
What's great is that it can completely remove software from macOS.
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:
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've noticed that --zap tends to leave a lot of traces still. Is it application specific?
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 ;).
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 ;).
There’s also AppCleaner for those looking for a GUI.
I use them both at the same time for most GUI apps. I have noticed that --zap tends to leave a lot of remnants still that AppCleaner sometimes picks up.
I've had two issues with homebrew that always bothered me:
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/.
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/.
Absolutely _love_ Homebrew. Thanks for all you (and the other volunteers) have done to keep it running!
Author here - thanks for everything you do to make Homebrew awesome!
Thanks for your work, it's a great package manager!
Mike, thanks for homebrew and thanks for being so active in this thread.
Homebrew is a great project and has been an incredible help for me.
Homebrew is a great project and has been an incredible help for me.
I love Homebrew. I find it especially useful on Linux, where it lets me avoid all the pain of distro-specific packaging.
I had no idea it was desirable or even possible to use homebrew outside of Macs.
I don't care Homebrew exists, except when I am forced to use it in some corporate laptops.
I am perfectly fine with macOS's UNIX™, out of the box experience.
I am perfectly fine with macOS's UNIX™, out of the box experience.
I'm glad that you're able to meet your needs without Homebrew.
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.
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.
Your comment was phrased in a way that looks like a question, hence the answer from my side.
What do you do when you need some library or command-line tool? Do you prefer to git clone and manually build from source? How do you keep up to date?
Most of the stuff is already available as classical UNIX, then,
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.
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.
Aha, so your solution is to just not do things which needs additional CLI tools or libraries. Got it.
That's not gonna work for me, or most people who use a package manager on macOS.
That's not gonna work for me, or most people who use a package manager on macOS.
Homebrew is a horrible thing for user who is not familiar with ruby syntax. Community do not have any user friendly how-to guides for developing new Formulae as well as weird tests like to long description or to long line.
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.
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 had literally never written any Ruby before contributing to Homebrew and now I write it for a living. This was when there was no documentation and now there is lots (https://docs.brew.sh, https://rubydoc.brew.sh).
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.
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.
I was like what? I’m not very familiar with ruby syntax and I’ve been a mostly happy user for years. But then I realized by user you meant someone who creates formulae, not someone who just uses it to install and manage packages
Happy to see op had a good experience with it. I chose to go back to MacPorts few years ago and only had splendid experiences with it so far.
Been using Homebrew since 2015, I’ve seen negative comments about it. While some of them are true, I still love homebrew because how well it works out of the box.
But If I know I am going to install multiple versions of a program ahead of time, I use asdf-vm instead
But If I know I am going to install multiple versions of a program ahead of time, I use asdf-vm instead
Does homebrew still want you to chown system folders?
No, the default Homebrew install location moved to /opt/homebrew on new Apple Silicon Macs.
(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:
https://github.com/Homebrew/brew/issues/9177
(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:
https://github.com/Homebrew/brew/issues/9177
/opt/homebrew isn't a folder provided by the operating the system, but it's still a "system folder" as in not a user folder. That's messed up. I have to imagine that this causes no end of issues on multi-user machines. The homebrew folder should either be somewhere under ~, or owned by root or some other system account.
I remember having one user account for my personal stuff and another user account for work on a personal machine (startup life) and needing to chown brew's install folders whenever I switched users. Extremely annoying.
Most macOS developer machines (our primary/biggest target audience) are not multi-user machines. It's not owned by root because Homebrew doesn't run as root (because the macOS sandbox doesn't run as root).
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.
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.
Most compiled software gets its installation prefix hardcoded at build time. If you move the directory elsewhere, then everything needs to be recompiled.
> you shouldn’t install outside the default, supported, best prefix
So you can, but apparently you shouldn't.
So you can, but apparently you shouldn't.
The problem is binary artifacts of compiled software. Those native binaries have hardcoded paths to dependencies and so by changing the location, you're forcing homebrew to compile everything locally to use a different path. It's the same reason Nix is still at /nix, despite the quirky installation requirements it forces on modern Macs with SIP.
There are tools to rewrite links in binaries, but they only work until you get a program calling dlopen or equivalent
There are tools to rewrite links in binaries, but they only work until you get a program calling dlopen or equivalent
I was simply responding to the statement
> its possible to choose a custom installation location, even on Intel Macs if you prefer.
Whilst it is physically possible, it won't work.
What would be better is a plan. Putting it in a different system folder like `opt` isn't much better.
> its possible to choose a custom installation location, even on Intel Macs if you prefer.
Whilst it is physically possible, it won't work.
What would be better is a plan. Putting it in a different system folder like `opt` isn't much better.
It does work, it's just not supported because the experience is worse. Open source (Homebrew included) is full of lots of plans: it's lacking people willing and able to execute on those plans. When or if that happens: Homebrew will support installations in more locations.
How is the experience worse if it works?
The other explanations imply that it may not work due to hard coded paths.
The other explanations imply that it may not work due to hard coded paths.
Because of the hardcoded paths, the precompiled artifacts will not work. Because of this, homebrew will need to run the build script locally. This means that the process takes longer, which is what makes the experience worse.
/usr/local/bin still wants chowned on Intel Macs but we’re looking at ways of being more liberal there too.
Nice. What about the default telemetry?
The default telemetry is:
- (still) not sent until we notify you that it's opt-out
- moved (this year) from Google Analytics to our InfluxDB instance (destroying all existing GA data)
- only kept for 365 days
- contains no PII
- no longer even attempts to identify individual users
- necessary to be opt-in in order for us to be able to effectively run the project
Imagine if you entered a party that had a big sign that says you consent to be groped by entering the venue.
"But we notified you!"
Consent does not work that way.
It keeps being pointed out that this is a nonprofit run by volunteers - this simply underscores your utter lack of a legitimate business use case for spying on your users.
The only reason people insist on opt-out (ie nonconsensual) telemetry is because they know they don't actually have consent and their ingest data would drop like a rock if they had to, you know, check with their users for consent before uploading their usage. It's the old "she never said stop!" dodge.
Consent matters.
"But we notified you!"
Consent does not work that way.
It keeps being pointed out that this is a nonprofit run by volunteers - this simply underscores your utter lack of a legitimate business use case for spying on your users.
The only reason people insist on opt-out (ie nonconsensual) telemetry is because they know they don't actually have consent and their ingest data would drop like a rock if they had to, you know, check with their users for consent before uploading their usage. It's the old "she never said stop!" dodge.
Consent matters.
Ah sneak, posting about analytics in every Homebrew thread. I thought you might like that we moved to InfluxDB but: no.
A new low for you by literally comparing an open source project gathering analytics to sexual assault and rape this time.
A new low for you by literally comparing an open source project gathering analytics to sexual assault and rape this time.
Colorful imagery aside, this kind of response is a "new low" unfortunately.
Rather than ad hominem, perhaps you could address the fundamental consent issue?
It doesn't matter how you store the data obtained without consent.
What you are doing is fundamentally unethical, and you only get away with it because most of your users are unaware that you are doing it.
I post about it because your users deserve to know what you are silently using their computer to do each time they install a package. You have fooled them (and yourself) with this distraction about a "notice".
It doesn't matter how you store the data obtained without consent.
What you are doing is fundamentally unethical, and you only get away with it because most of your users are unaware that you are doing it.
I post about it because your users deserve to know what you are silently using their computer to do each time they install a package. You have fooled them (and yourself) with this distraction about a "notice".
[deleted]
It's still opt-out, but they moved from Google Analytics to their own self-hosted InfluxDB for increased privacy.
[deleted]
Homebrew is awesome. It installs 80% of my macOS apps.
To everyone who created, maintains and improves Homebrew - thank you! It's an awesome solution that makes things really easy. Your work is appreciated.
Doesn't S3Scanner seem like a weird thing to have in the Homebrew "core" repository, rather than be in its own tap?
If it’s open source, doesn’t have a hilariously overinvolved and unreliable build process, is used by more than just the author: it’s best in the main repository.
[deleted]
Homebrew is horrible. Want to update a single package? All hell breaks loose. Suddenly some weird version of Perl is being installed, and after that python is getting autoupdated. Make no sense at all. pkg-src is a better option.