Anyone know why Homebrew overtook MacPorts? I only have a vague recollection of a Rails colleague pushing me to switch circa 2013 or so and haven't given it much thought since, but it (MacPorts) seemed to be similarly ubiquitous prior.
When I started using a Mac in 2009, MacPorts, Fink (and I think there was another I can't recall the name) simply wouldn't work for me. They would take very long to build what I wanted, there weren't nearly as many packages as was in Debian/Ubuntu, and many were old versions. Worse, many build attempts would just fail.
In that scenario, brew worked like a charm. It was quick, had most or even more packages than Debian/Ubuntu and they were newer. Failure to install was rare.
Then, Apple started yearly release of OS X, and that both broke brew and my system hard, so I started investigating and found out about the many "shortcuts" that brew took and how it violated systems components. I was dismayed, and abandoned brew for good.
So, I stood a period where I would use many of my tools inside a Ubuntu VM, until probably 2013-2014, when for some reason I tried again MacPorts, and I don't know why, but that time it was much more reliable, and because of Apple's insane atm SSDs with 2 GB/s bandwidth, install became quick enough. Packages were still somewhat lagging behind in available versions, but the variety of them kinda reached the levels of what was in Debian/Ubuntu, so it was good enough for me.
Then, the killer feature, I found out about macports variants and selectors, which I find the most awesome thing to this date in package managers (I haven't tried nix, still, it might be magnitude better in that regard). No needing to use rvm, pyenv, custom installs of gcc messing with make/autotools, and the only sane way of compiling various Haskell projects (before haskell-stack).
I don't know when they introduced it, but I believe MacPorts will build the common variants of the more-used packages. So, if you install a package with the default variants, you'll get a binary download instead of building from source.
But indeed; fast SSDs, parallel compilation, and modern CPUs really help!
MacPorts was slower (bringing in its own dependencies for everything meant longer build steps) and required sudo more. There were some annoying fiddly parts that made it seem like the homebrew users around you were having more fun exploring packages.
It was also exciting how many packages and casks were in homebrew and it was easy to make your own.
Also, back then there were lots of people experiencing package managers for the first time and they took to homebrew easily.
Then so many projects started to publish brew install links as a way to get started; homebrew felt like a default.
Now, with our faster computers, more space, and more packages installed, and macports shipping more binaries and using its own normal user, macports' duplication of dependencies looks more like an advantage than a disadvantage. And because homebrew taught so many people how to use package managers, macports is not their first so easier to start using.
> Also, back then there were lots of people experiencing package managers for the first time and they took to homebrew easily.
I suppose it was almost 15 years ago now but this is what I recall. Homebrew was easier, snappier, and the general friction coefficient felt smaller.
It's a little funny reading this and then wonder... Why did I leave MacPorts behind? I don't think I put much thought into it at the time and rather went by feel. I was still somewhat new to this stuff having started my career more in design than development.
- it has always had a strong emphasis on presenting a simple, clean, pleasant, pretty, playful UI and executed that well
- when it came out, source-based package managers for macOS generally didn't have any binary caching mechanisms, so compile time mattered
- Homebrew's embrace of the base system as opposed to bringing its own dependencies bought it greater reuse at the cost of robustness, driving down total time to install many packages
- the language that `brew` and its packages were written in was trendy at thw time as well as pre-installed on macOS, which made them instantly accessible to huge numbers of web developers
- the older macOS package managers generally drew on traditions and tooling from the Linux world (e.g., Fink, with Debian tooling) or the wider Unix world (e.g., MacPorts and various *BSD ports systems and packages written in some Tcl IIRC).
The type of person with the experience that would lead them to prefer tools and conventions like one sees in Fink, MacPorts, and Pkgsrc, or to contribute to those projects, has likely always been dismayed, if not repulsed, by a number of Homebrewisms. I think we can therefore conclude that Homebrew didn't win the package availability race by converting MacPorts contributors— Homebrew succeeded in attracting a largely untapped pool of new contributors. Eventually there followed the majority of non-contributor users who just want to use whatever already offers the software they want to run.
At the point I switched from MacPorts to Homebrew, homebrew just worked more reliably in my experience. It installed things quicker and with fewer build/install failures. i don't know enough about what was going on under the hood to have any theory as to why this was my experience; I don't want to know what's going on under the hood, I just want to type `install whatever`, and have it work.
I guess MacPorts was (and is) geared more towards users with some proper UNIX or BSD background, e.g. people coming from FreeBSD.
Whereas Homebrew targets the typical Mac user who might need a CLI application occasionally, i.e. someone looking for simplicity, without being too technically savvy.
The latter group certainly makes up a much bigger share of users on macOS, especially nowadays.
When you installed a port with macports the idea was to use as much of the macports for build and runtime dependencies. Over time that became greater and so port install would be slow until you built enough dependancies. It also consumed more storage.
When you installed a port with brew it used as much of the OSX, X11, and XCode installed utilities as possible so it was faster and used less storage. But then you would install an update from Apple and things would break cause of that reliance, things like /usr/bin/perl.
People like beer but also Homebrew had a cute site and made ports simpler than MacPorts. Turns out complexity was maybe not unwarranted. I was among first adopters of brew but now I port for years
this was a while back, in the Gentoo Linux heyday, so it was popular to compile things, except that this was when computers were slow, so that meant waiting for compiles. the problem with macports was that (iirc, it's been a while) it compiled its own version of Python instead of just using the system python, which also broke sometimes. and then you had to compile all that shit again. brew won out because it was faster, and didn't duplicate redundant shit for no perceived reasom.
