MacPorts does also still drop to compiling from source more often than Homebrew. But that’s mostly because they take a more conservative legal approach towards the GPL—for instance, they won't distribute binaries of any GPL software that links with OpenSSL.

Also, ports for older/ancient versions of OS X are frequently source-only, but since Homebrew doesn’t support such systems at all, it's not really a fair comparison.

(As an aside, MacPorts must have the most incredible legacy support of any Mac project, ever. They had ARM working within a week of the M1’s release, largely because all of the infrastructure for multi-arch was already in place—to support users on PowerPC!)

> Also, ports for older/ancient versions of OS X are frequently source-only, but since Homebrew doesn’t support such systems at all, it's not really a fair point of comparison.

On an old, unsupported, system homebrew drops down to compiling. just the other day it compiled for four hours just to update one program. kinda infuriating really since there are downloads for those packages still.

I'm surprised it still works, to be honest–Homebrew is usually fairly aggressive about dropping support for older systems.

We don’t support any scenario where things are built from source (i. e. we won’t help you if things break) so technically support has indeed been dropped.

Is there no way to enable downloads of builds in homebrew on those systems with the caveat that perhaps it'd have to go back to compiling if there aren't any?

The bottles no longer exist.

The nodes that used to build High Sierra bottles have been re-commissioned to build Big Sur bottles.

This is a weird take.

Homebrew not only installed from source for a long time, when they implemented installing prebuilt binaries, they half-assed the dependency resolution of it, so the binary version of a package would always end up requiring the binary version of the first of any alternate dependencies (ie if A requires B or C, binary pkg A will always require binary package B, and won’t accept C).

Ah, you're right. Now thinking back, I think it was how Homebrew reuse system libraries that make it a better experience than MacPorts at the time since it could cut over half of the building time (it prevent the situation where `port install sl` ended up having to build the entire gcc toolchain). This was actually why "reuse system library" were such a big deal back then. Bottle come much later than that.

The other downside to MacPorts' original way of building everything is that sometimes, for whatever reason, things just wouldn't build and getting help with that was thorny, particularly for those who'd just started dabbling in software development or CLI usage. Where a vet or moderately seasoned user might find the thrown error actionable, the new user would google the error, find a couple of semi-related but ultimately unhelpful archived mailing list threads from n years ago, and probably give up and find some other way to get the package they need.

Just today my new config for Emacs refused to build libgit. I could see the CMake error, but rather than figuring out how to fix it I just commented out that part of my config (resulting in slightly more overhead in magic). Even with many years of serious software development, I really don't like debugging build problems.

I used to use Fink and MacPorts for MacOS package management, but brew was so easy to use that it won me over.

This is one reason why using Rust crates in cargo's current form irritates me, if I wanted that kind of experience I would be using Gentoo as daily driver.

All the other languages I use support binary libraries on their package managers.