With so many other package managers available, I often wish something else was the de facto package manager on macOS. Something like pkgsrc, which follows conventions much better and is thereby much easier to manage.
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).
But indeed; fast SSDs, parallel compilation, and modern CPUs really help!
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.
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.
Homebrew had at least these things going for it:
- 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).
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.
- brew had and has many more packages available
- brew updates versions more quickly
- brew uses much more simple paths that fit my brain better
- brew has a pleasing simplicity
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.
My first exposure to Mac package stuff was fink in the early aughts - compiling everything on a Pismo G3 was pretty slow going
I’m really disappointed in how Homebrew took a lot of attention away from the existing package managers, made a bunch of terrible decisions related to packaging and flexibility and genera Unix philosophy, and then ate the world.
: shakes fist at clouds, get off my lawn
Note that Pkgsrc is a NetBSD-derived project.
The Joyent folks leveraged it to allow their customers, who were perhaps not as familiar with Solaris/SmartOS, a larger pool of packages. Pkgsrc was running on Solaris before Joyent, Joyent built on top of it.
1. Not available at all in nixpkgs (e.g. Docker Desktop, BetterTouchTool, etc)
2. In nixpkgs, but completely broken or missing some architecture support (e.g. Firefox)
3. Actually available and somewhat functional in nixpkgs, but some significant features don't work because of code signing requirements and needing to be managed in the Applications folder (e.g. 1Password)
Quite a few tools do in fact work well with nix on Mac. Especially if it's FOSS and/or a cli-only based tool. And for FOSS tooling such as Firefox, there is often a convoluted workaround (I'm currently using `github:bandithedoge/nixpkgs-firefox-darwin`). And of course you can always package it yourself by doing things The Hard Way.
But the platform is still quite a ways away from being able to be used as a daily driver on Mac without Homebrew.
For alacrity, I remember it being annoying to integrate into Mac's launcher, but it otherwise worked.
Pretty much everything else was programming-related and just worked.
I don't use very many GUI apps so now that the installation piece is taken care of, I can just package everything I use if it really comes down to it. That'd be worth it for me just to get rid of the painfully slow `brew` invocations that lurk in my activation scripts.
--
I hacked around a bit trying a few different approaches before giving up and switching back to the regular nix-Darwin homebrew approach. But the issue is probably solvable by someone who knows a lot more about how the code signing process works with Macs and the Applications folder
(Spotify didn't build because the Brew package doesn't have a hash, and Karabiner Elements didn't build bc idk why, but that's actually in Nixpkgs already and that version works fine.)
I did double-check that I have SIP enabled and everything. I'd be interested in trying to repro!
Aside: that mac-app-util works so nicely for the macOS apps that are already in Nixpkgs makes it feel much more worth it to me to package GUI apps for macOS, if that'll mean I can get rid of `brew` entirely. I wonder if this will spur others to also package more GUI apps this way.
VScode in particular was the one that broke for me, though that is actually available and mostly functional in nixpkgs so that one is not a showstopper.but might be a good test case to repro
Oh, here's that issue: https://github.com/maxgoedjen/secretive/issues/77
1Password definitely acts weird for me, to where I kind of wonder if the .app folder is malformed somehow. The version installed in the Nix store actually works fine-- but not if I double-click it or open it with the `open` command. In that case it kinda acts like something is going to launch but then it never comes up. But if I manually invoke `/Applications/Nix\ Apps/1Password.app/Contents/MacOS/1Password` from my terminal, it starts up fine! But when I directly launch that executable from Finder, the application does not start and I see that same message about not living in /Applications printed in the terminal. Idk why 1Password refuses to run from anywhere other than /Applications but that seems to be it's message rather than the operating system's.
It's a shame 1Password's Mac app can't run from the Nix store. They clearly have at least one Nixer at the company because they have cool integrations like this:
https://developer.1password.com/docs/cli/shell-plugins/nix/
I couldn't even get the Docker Desktop package to build from `brew-nix`. OrbStack in the Nix store died on signature errors, but when I visited Security & Privacy in System Preferences after that, there was a little notice that OrbStack had been blocked from running because it was from an unrecognized developer, with the option to allow it. After being allowed, it seemed to work as normal. Same for Podman Desktop.
Why do the signatures for those apps end up getting replaced with this setup anyway?
I was curious about your final question as well, but I know little about how this works. The error when I tried vscode looked to be that the signature had gotten malformed somehow during brew-nix’s copy operation but since I had no idea what a correct signature should even look like I got stumped there.
I use brew, and have used pkgsrc in the past. I could go back for low pain.
pkgsrc is by far the most KISS package manager for macOS, I like it.