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.
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.
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 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/.
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.
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 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
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
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.
To everyone who created, maintains and improves Homebrew - thank you! It's an awesome solution that makes things really easy. Your work is appreciated.
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.
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.
mikemcquaid|2 years ago
pseufaux|2 years ago
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.
joshstrange|2 years ago
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.
widdershins|2 years ago
BigJ1211|2 years ago
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.
wellthisisgreat|2 years ago
l72|2 years ago
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/.
sparker72678|2 years ago
salmon|2 years ago
rickette|2 years ago
Affric|2 years ago
Homebrew is a great project and has been an incredible help for me.
ripley12|2 years ago
pjmlp|2 years ago
I am perfectly fine with macOS's UNIX™, out of the box experience.
dengolius|2 years ago
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.
mikemcquaid|2 years ago
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.
SOLAR_FIELDS|2 years ago
michelangelo|2 years ago
Alifatisk|2 years ago
But If I know I am going to install multiple versions of a program ahead of time, I use asdf-vm instead
happymellon|2 years ago
jez|2 years ago
(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
unknown|2 years ago
[deleted]
bhouston|2 years ago
danhodgins|2 years ago
justinclift|2 years ago
mikemcquaid|2 years ago
unknown|2 years ago
[deleted]
phplovesong|2 years ago