At that point in time I was a lot less technically capable, so on the rare occasion googling the issue would turn up a relevant mailing list archive, I usually wasn't able to act on it and I'd wind up procuring the package in question through some other method or just doing without.
So when Homebrew came along and most things installed and ran fine with the rare issue that cropped up getting fixed fairly quickly, it easily stuck.
- before, I had generally heard of homebrew a lot, and macports very little. Brew's marketing is better. I think this is intentional (as in Macports doesn't really do any)
- The docs for macports are very poor. They are comprehensive, but barely navigable. Keyword search doesn't work well. They're obtuse.
Further context: I also find brew docs poor, but they're much more user-focused (how to install packages), whereas macports' seem more packager-focused.
- Requiring sudo is a security feature, but Macports doesn't advertise this well, so brew "seems" more secure on first impression
- Most software with cli install instructions recommend brew up top (even when there's a macports option). i.e. there's no evangelization of macports by maintainers who package for it. I don't really know why this is, but it's something macports maintainers could/should look into.
In reality however, macports uses "privilege separation" which drops privileges for each individual install to a separate "macports" user. This is more secure than brews sudoless approach because not only does the installer not have root access, it doesn't have full access to your own user either (e.g. your HOME). Privilege separation isn't possible without initially having root privileges.
The most common complaint (changing permissions on /usr/local) isn’t a problem with the arm64 version which now uses /opt/brew but, also, as far as my trust model goes, it isn’t a problem for me: I already have $HOME/bin on my path and, so, any local exploit that relies on overwriting system executables has multiple ways of tricking me into running a malicious program.
Homebrew was the cool new kid at the right time, when Macs popularity amongst webdevs was growing exponentially. OTOH, Macports is still working fine; there is room for two package managers on macOS.
I wasn't able to get it to work, and it left a bunch of users (like ten??) and other various junk which was a pain to clean up. This was in 2017 I think.
I keep hoping someone will chime in and say "I use nix on my Mac, and it's dreamy, everything Just Works you should try it!" because until that happens I'm going to stick with brew.
While I'm on the subject, I was also a macports user until hmm, 2013 I think. Don't recall exactly why I switched, just that I was having some kind of intractable problem, messaged a friend who knows what he's talking about, and he said "just use brew dude". So I did.
Well, it works now that I've set it up. But the setup is not exactly trivial. Here are the steps I used last time I set it up, a year or two ago, to get a single-user install working:
```bash
sudo vim /etc/synthetic.conf
# Insert the following line in vim (the file should be three bytes long):
nix
# Save and exit vim
echo "LABEL=Nix /nix apfs rw" | sudo tee -a /etc/fstab
# Reboot computer
sudo diskutil apfs addVolume disk1 APFSX Nix -mountpoint /nix
sudo diskutil enableOwnership /nix
sudo chown -R "$(whoami)" /nix
# Reboot computer
sh <(curl https://releases.nixos.org/nix/nix-2.3.10/install) --no-daemon ```
So not exactly pretty, but it works. And it works great. Nothing every breaks -- installations/updates may fail, but they leave the previously working version in place so that everything works as if I hadn't tried to install/update in the first place. I wouldn't want to have to set it up again, but now that I have, I don't want to use anything else to manage my packages.
Brew was a big timesaver back then (maybe now too if macports is still in 'compile everything' mode) and that is the key reason why it became the dominant package manager. Nobody has 'moved back' because macports isn't 'better enough' to induce people to switch over like they did with brew originally.
The optimization opportunities for some packages are typically on the order of 2x-5x faster, which isn't enough to deal with the headache of extra config for a personal dev box. So, my rule of thumb is, unless I know exactly the performance trade off I am trying to take advantage of by going with MacPorts, I will be better served by using Homebrew. I will wind up spending more time fixing config then I will have saved on execution processing time.
As does MacPorts. https://guide.macports.org/#installing.xcode
> MacPorts builds everything from scratch
This has not been true for many years: https://trac.macports.org/wiki/FAQ#fromsource
For some reason, It is PITA to get MacPorts to recognize Xcode. It took me three days to get MacPorts to see it. I tried various configuration, arguments, versions, etc until it's finally working.
That specific issue sounds like a MacPorts problem where it (MacPorts) is using an outdated version of Erlang; because Erlang works just fine on the M1.