Thoughts on macOS Package Managers

Not to pile on, but I thought Homebrew handled the Python2 -> Python3 cutover poorly. A routine `brew upgrade` resulted in python being de-syslinked. For me, this meant a bunch of tasks broke silently in the background. It took a little while to find out that it was just the case that `python3` became the default interpreter and thus I needed to install some dependencies for scripts running in the background.

It's totally fine as my code was python3 compatible, but I was surprised that they'd apply a breaking change like this silently. Unlike OSes which might do this kind of thing with a major version update, I was surprised, and it took me a little while to diagnose what happened.

When I checked the GitHub discussions about the change, I found two things: 1) The maintainers claimed they had given a soft deprecation message a few months prior -- but brew doesn't stop for user input, it just posts walls and walls of messages, so I had naturally tuned it out. 2) The maintainers were getting ballistic mad at people who didn't think this was handled well.

Of course, open source is open source, and maintainers owe us nothing, but I was surprised that such a critical piece of infrastructure was being managed by people who imho handled a potentially non-trivial transition like this and who clearly didn't have the diplomatic tact to handle their userbase.

I moved to Homebrew a few years ago because MacPorts was significantly slower in adding new versions of some of the packages I needed to use for work. I had resisted using Homebrew until that point because the architecture of MacPorts made more sense to me, and because Homebrew's permission model in /usr/local is terrible.

At this point it seems like Homebrew is the standard -- I frequently see open source projects recommending it in their installation instructions without mentioning Macports.

I also recommend Homebrew to friends and coworkers, for the reasons I already mentioned, and also because it is significantly easier to install. Go to their website and the first thing you see is an installation script. Go to the MacPorts website and you see a link to an installation page partway down. That installation page is very long and lists a number of prerequisites needed for the installation to work. Homebrew does the installation bit way better, thus making the barrier to entry far lower.

MacPorts would need to demonstrate significant advantages over Homebrew to get me to switch back.

I'm pretty sad it doesn't explore Nix as it's superior in isolating and doesn't require root.

Getting started: https://medium.com/scientific-breakthrough-of-the-afternoon/...

How much effort was put into making the whole isolation: https://www.youtube.com/watch?v=73mnPBLL_20

There is even a declarative way to setup darwin process management: https://github.com/LnL7/nix-darwin

I used to use MacPorts, and switched to Homebrew. For exactly one reason: Homebrew uses, whenever possible, the tools already built in to macOS, where as MacPorts builds new versions of those tools in order to maintain a pristine build environment.

MacPorts' philosophy seems better in theory, but in practice it has two flaws that turned out to be very significant for me. The first is that you end up needing a huge number of ports, partly because you're duplicating the tools already on the system, but partly because in many cases you need all of those ports' dependencies as well. So upgrading anything was a huge processing sink. I wanted fifteen or twenty ports on my system, but to get those MacPorts had to install several hundred dependencies. If you ever decide you don't want one of those ports, the dependencies are still installed, and pruning the ports tree was decidedly nontrivial.

The second was dependency hell. You end up with at least two versions of everything. Which one random third party apps pick up depends on search paths. Different third party apps need different versions, and I ended up twiddling with search paths a lot. Tryin to install ROS as a standalone third-party package was a nightmare.

Homebrew has its issues, but it doesn't have these issues.

Ultimately the real problem here is that macOS package managers are bolt-on additions and not a core part of the OS. when that's the case there is not going to be any perfect solution. But for a single-user machine where the main goal is to be able to maintain a minimal set of installs, and install new ones quickly so you can get real work done, Homebrew just worked better for me.

Good piece.

Homebrew is certainly "opinionated" and, as the article says, "abrasive".

I recently had one of those upgrade chains: new iOS needs new Xcode, new Xcode needs new OS (Mojave), new Xcode and OS need new Boost. All fine up to this point.

I'd installed Boost via Homebrew. So, fine, brew upgrade boost.

A bunch of stuff scrolls past... holy ---- it's upgrading Postgres?

Oh great. Now a whole bunch of work I have stored in a Postgres database is inaccessible. No problem, Homebrew apparently has a Postgres upgrade script now.

Except it wouldn't work, complaining "no upgrade path" from PostGIS 2.4 to 2.5.2; and Homebrew wouldn't install both at the same time. Eventually, after much experimentation, I found Postgres.app came with all the right versions, allowing me to pg_dump it all out.

But my word... while trying to figure this out I spent hours looking through the issue tracker, and the state of it. Endless snark about "we don't support old versions". Fun like this: https://github.com/Homebrew/brew/issues/5675#issuecomment-46...

It's a good tool, just don't expect any support with it, ever. I kind of feel that Homebrew's slogan should be "Homebrew locked as resolved and limited conversation to collaborators".

Homebrew maintainers editing other people comments is intolerable: https://news.ycombinator.com/item?id=19066630

Homebrew isn't great but having to manually remove and reinstall all macports every os upgrade, having to deal with messed up dependencies and debugging failed compiling errors manually, and having macports libraries conflict with other mac software and making it crash was just too much. I need at best a few tools provided by these package managers and I don't want to spend hours messing around with their configurations. I just want them to work. Brew used to have issues for me but the last couple of years it's been the least buggy experience. That's all that matters. I don't give a fuck if it uses sudo or not, where they store files, or even if I have to disable system protection. All that is simply irrelevant. I just want things to work so I can get my actual work done. That is what makes a package manager better and that's why brew these days is much better than macports.

Something has always rubbed me the wrong way about homebrew. I feel like there is something about it that doesn't quite jive with Unix philosophy. It doesn't feel like a Unix tool, vague as that sounds. Assuming ownership of /usr/local as this author complains is along those lines.

It just always seems like between "just get it kinda working" and "work how I expect" it often picks the former.

Reading those homebrew comment threads convinced me to switch to MacPorts. I don’t care if you’re a volunteer, that’s not how you treat users.

Shame there is no mention of pkgsrc, I've been using it for years.

https://pkgsrc.joyent.com/install-on-osx/

Great article. Really puts into words many complaints I have against Homebrew. The non-sudo thing doesn't bother me, its the leadership. User-hostile is definitely the way to put it. I don't anticipate leaving Homebrew any time soon, but it sure would be cool if the maintainers were nicer. A favorite thing to say is that they don't owe the users anything, but I think that they forget that a lot of users are contributors too. And they would probably contribute more if the maintainers were a little nicer.

As much as homebrew has its flaws, I don't want to use MacPorts until it supports binary packages as well as building from source. It's something even FreeBSD understood; not everyone is running on 8 core machines, and I don't have the time to build GCC or LLVM on a midrange laptop CPU. No one I know uses Homebrew because it's awesome, but because they wouldn't even consider for a split second a solution that involves waiting for hour for stuff to finish building from source.

When I moved from Linux to Mac (started iOS development and got sick of tinkering to get stuff working), I looked at both homebrew and macports.

As soon as I saw that homebrew wanted to use /usr/local instead of /opt, I avoided it. These days, /usr is part of the system, even though GNU still uses /usr/local as the default.

/opt matches where the LSB says "3rd party packages" should be installed, MacPorts is (or was) partly sponsored (and thus "blessed") by Apple and it matches the "port" packager that is used for FreeBSD.

Yes you have to do some PATH and LDPATH tricks to make sure that /opt/local/* is at the top of your paths, but other than that, MacPorts has been painless.

There are some steps to follow when a new version of Xcode (and effectively a major release of MacOS) comes out, but that's more about getting xcode to accept you've accepted Apple's license.

Homebrew removing options is such a silly thing. Changes nothing in the end result, just makes things a more inconvenient.

There’s also https://pkgsrc.joyent.com (yes, for MacOS too).

Great article, having used both package managers I can relate. Neither one is perfect, but MacPorts tends to be FAR more reliable.

> MacPorts almost always builds packages from source

That’s a misconception. As of 2019 a properly-configured MacPorts will download almost exclusively binaries.

I’ve always get off about Homebrew, but never put words to it. Many of the comments here seem to mirror my feelings.

From the beginning it was as if no package managers had ever existed and they were solving packaging problems for the first time ever and ignoring not just the other Mac package managers but other package managers in general.

Then there’s the smattering of cutesy names for internal concepts: bottles and casks and tapping.

Popularity of Homebrew skyrocketed, though.

Meanwhile, MacPorts is better than ever.

Why not use Nix package manager if you're looking for an alternative to homebrew?

My personal beef with Homebrew is the amount of work they create for third-party "tap" (package collection) maintainers by constantly making breaking changes to the formula interface.

For example, Homebrew used to support compiling on both 32-bit and 64-bit systems. They provided a "is 64 bit" function that packages could use to check if they were being compiled on a 64-bit system. It worked great!

Then, Homebrew decided they no longer wanted to support 32-bit systems. Instead of doing what any reasonable project with a stable interface would do and modify the "is 64 bit" function to always return "true", they just deleted it! I found out when one of my users emailed me to let me know that my packages crashed when you tried to install them.

Changes like these mean that I spend 20% of my package-maintainer time on real work and 80% dealing with Homebrew's nonsense. Moreover, they show that Homebrew doesn't care at all about the people who maintain packages outside homebrew/core. And as someone who maintains packages outside homebrew/core, that makes me not want to continue.

Can't use Homebrew for any stable operations.

I had a project that has Ruby set at version 2.5, one day Homebrew turned it into 'ruby@2.5' and now 'ruby' was 2.6 and whenever @2.5 also upgrades, since there is no global symlink, a minor version change breaks my IntelliJ setting as the path has slightly changed.

I was using Ansible from my local Mac but dropped it thinking this might just break one day. Linux distribution vendors do far better jobs at keeping things 'as is' for years.

The only use for Homebrew for me is to install individual tools that don't have wider impact if it breaks (like ripgrep).

The permissions black magic is really upsetting to me---undoubtedly, I freely and openly admit, because I don't really understand permissions, but it seems to engage in behavior that it shouldn't be able to engage in. As recounted in this old blog post[1] it does things like change the permissions on its own files even after one declares the owner to be root and sets the file as non-writeable. Now, like I said, I don't really understand how file permissions work, so I'm sure that there's a perfectly logical explanation for how that's possible---but it hardly seems consistent with the incessant claim the homebrew maintainers make that it doesn't require elevated privileges.

[1] https://paultopia.github.io/posts-output/anti-homebrew/

Interestingly, they now seem to have ~US$3k/month via Patreon:

https://www.patreon.com/homebrew

Wonder if they'll use it for paying maintainers or something? It's a useful amount for planning things out with. :)

Disclaimer: I'm a MacPorts committer.

> MacPorts almost always builds packages from source

Many packages in MacPorts (including LLVM) have pre-built binaries available from https://packages.macports.org/ and its mirrors for macOS releases ranging from Mac OS X 10.5 to macOS 10.14.

But if a port is considered not distributable because of its restrictive license or license conflicts with dependencies, binaries will not be uploaded to our official mirror so users have to build it from source. We don't provide official binaries for non-default variants or alternative prefix (the default is /opt/local) either, but organizations using MacPorts can set up private mirrors with custom ports and binaries.

port_binary_distributable.tcl[1] describes the license conflicts. e.g. "git" is not distributable because its license "gpl" conflicts with license "OpenSSL" of dependency "openssl".

> MacPorts seems to be a bit lacking in manpower (which makes things takes slightly longer than I would have expected)

Yes, we need more contributors and committers to maintain the large collection of ports we have. Our ports are more often outdated than Homebrew because of this and our maintainer policy. We are also seeking for ways to improve our developer experience, e.g. https://github.com/macports/macports-base/pull/120 which automates updating checksums in the Portfile.

> The lack of color, as well as somewhat more cluttered and less relevant output, makes it a bit less pleasant to work with.

We talked about this in a meeting last year, but it hasn't been implemented yet. https://trac.macports.org/wiki/Meetings/MacPortsMeeting2018/...

Development of the port command is relatively inactive (severe lack of manpower). https://github.com/macports/macports-base/commits/master

> MacPorts will set up its own tools in isolation from those provided by the system

Its own versions of libraries, to be exact. See https://trac.macports.org/wiki/FAQ#syslibs for more background on this.

> builds run in “sandboxes” under the macports user, where attempts to access files outside of the build directory–which includes system tools–are intercepted and blocked

It will block writing files outside of directories specified in portsandbox.tcl[2], but using (reading and executing) system tools is allowed. For example, most ports are built with the compiler from Xcode.

> The upside is that this approach is significantly more contained, which makes it easier to manage and more likely to continue working as macOS changes under it.

Yes, but we recommend users upgrading to a new major release of macOS reinstall MacPorts and all ports because things could still break. We have a migration guide here: https://trac.macports.org/wiki/Migration.

[1] https://github.com/macports/macports-infrastructure/blob/mas...

[2] https://github.com/macports/macports-base/blob/master/src/po...

npm installation is broken with brew. had to use the standalone installer coz none of the workarounds would add npm to the path correctly(brew has some problems with access permissions and can't be sudo forced to get those permissions)

kinda irritating

The sudo-less operation of homebrew bothers me greatly too :/

But I just want to say thank you very much to The Homebrew team, if you're reading this, I really appreciate your efforts.

I previously had many issues with MacPorts but I am certainly going to be revisiting it.

Where to begin. it's a Homebrew hit-piece extolling how the inaccessible and system-modifying MacPorts is "superior." Bologna! I don't trust MacPorts, it's old, confusing, has terrible UX and promotes system-entropy increase (read: weird gotchas and eventual reinstalls). Leave my goddamn system alone. I don't trust giving a community package sudo.. ever. I don't pipe bash into shell, so no sudo for you either, mister package manager.

No sale.

MacOS was not made for multi-users on one machine.

Am I crazy to refuse to use a package manager on macOS? I thing that you should just follow the instructions and understand how to install a project. As an example, I use a lot FFmpeg, just doing brew install ffmpeg does not make sense for me; there are so many options... you need to understand what they are and the implications...