[mikemcquaid]

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.

[pseufaux]

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.

[joshstrange]

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.

[widdershins]

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.

[BigJ1211]

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.

[50]

> 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/

[FireBeyond]

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.

[wellthisisgreat]

Homebrew is among the top-3 reasons I enjoy developing on Mac. Thanks a lot for your work!

[bartvk]

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:

    brew uninstall --zap google-chrome

You can view the formula as follows:

    brew info --github google-chrome

Look for the zap stanza, there's a whole list of folders.

[hirvi74]

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 ;).

[supriyo-biswas]

There’s also AppCleaner for those looking for a GUI.

[hirvi74]

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.

[l72]

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/.

[sparker72678]

Absolutely _love_ Homebrew. Thanks for all you (and the other volunteers) have done to keep it running!

[salmon]

Author here - thanks for everything you do to make Homebrew awesome!

[rickette]

Thanks for your work, it's a great package manager!

[Affric]

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.

[ripley12]

I love Homebrew. I find it especially useful on Linux, where it lets me avoid all the pain of distro-specific packaging.

[noman-land]

I had no idea it was desirable or even possible to use homebrew outside of Macs.

[pjmlp]

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.

[mikemcquaid]

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.

[pjmlp]

Your comment was phrased in a way that looks like a question, hence the answer from my side.

[mort96]

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?

[pjmlp]

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.

[mort96]

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.