I moved from Homebrew to MacPorts on a local, personal-use Intel Mac.
I chose Homebrew some years ago when I was not as experienced a programmer, because it was more popular than MacPorts. When I revisited the choice last year, I chose MacPorts.
On Homebrew:
* It has a Frankenstein permissions model; for example "brew install" writes files into /usr/local/* with your regular user account as the owner of the files.
* The permissions model means that Homebrew-managed parts of the system become a single user system, as far as I know. Multiple user accounts on the same Mac can't easily use Homebrew, as far as I know, and I dislike software with such design choices.
* Noisy messages and undesired colors in the command line output.
These issues are absent in MacPorts. Overall, MacPorts appears more mature and more Unix-like than Homebrew.
The cons of the move are that not all the packages I want are available in MacPorts. However I have sufficient experience now to package crucial missing ones into MacPorts.
> permissions model means that Homebrew-managed parts of the system become a single user system, as far as I know. Multiple user accounts on the same Mac can't easily use Homebrew
The single user thing is problematic in a corp env where you may have a mgmt admin user and a non-admin dev user.
Long story short, temporarily have the dev user be an admin, install brew, drop the admin priv. That works for cli tools (which is actually great), but may not work for /Applications unless you change its ownership. Used to be OSX effectively (not literally) merged ~/Applications and /Applications, but now in MacOS the security sandboxing and entitlements don't like that.
I switched from MacPorts to Homebrew very early on because it was better contained. I had to support developers who would build with MacPorts and end up with something which would crash with a linker error when they shared it with someone off the team because it was using a MacPorts binary in a non-standard location, or whose shell scripts broke expecting a GNU CLI utility version which was in their path but not their users. MacPorts also took forever to build since it dragged in so many replacements for system libraries.
Homebrew has done a much better job of staying out of the way.
Moved from Homebrew and Nix to MacPorts for a while around the M1 transition. Came away quite liking MacPorts; it was simple, and it worked.
Moved back to Nix when it was ready for Apple Silicon, mainly for better isolation / reproducability, ephemeral environments, and parity with my other systems. But if I need something that's not in nixpkgs, I'll look at MacPorts first.
1. I have used Fink. And I have used MacPorts. Now I use Homebrew.
2. When I get super-annoyed with a system, perhaps because it has entered a state where it won't update, I do a web search to see if folks have jumped from that ship to another. If there is a consensus, I jump with crowd. If not, I try to clear the decks, e.g. reinstalling from scratch, to see if I can improve my situation.
3. I don't have a list for you on the pros and cons. There may be some merit in choosing a system that is widely used, because then others might be able to help you if you encounter problems. By that measure, I think Homebrew is the best choice at the moment. But I've no reason to think there won't be something else just around the corner. I wish Apple would get in this game, but after so many decades of Apple standing by without acting, I am not especially sanguine.
Macports had broken multiple times in a year, under totally ordinary operation (nothing weird, just installing and uninstalling packages without doing anything that ought to be risky). A couple times I'd decided it was easier to just delete its entire directory and start over. Big rpm-hell vibes from the bad old days.
Switched to Homebrew. It's broken a couple times in a decade or so, only on OS upgrades. Easy fixes. I like the sudo-free package management. I like that it lets me manage a lot more of my software than Macports did (bigger selection, and "casks" for commercial software, which are now integrated into the main UI so that's not even some extra thing to learn anymore—it feels like being back on Gentoo with a good binary package cache)
I have zero experience with pkgsrc. From a first glance (from pkgsrc.org), I can say that nix claims to have 80k packages whereas pkgsrc 26k. Also, nix'es main selling point is reproducible builds, which is pretty cool. Other than that, nix is satisfactorily fast (much faster than homebrew, not sure in comparison to pkgsrc).
Switched to MacPorts on an older machine which Homebrew dropped support for (and deleted all prebuilt binaries)
While neither is great as a package manager, especiall with their dependency resolution, here are a few pros&cons:
Apps: ++ Brew has a much more up-to-date collection, also more non-source binaries.
App customization:
+ Port, Brew dropped support for custom install flags a while ago
+ Brew you can setup autoupdate for your personal customizations with github actions since the main repo is using them, Ports does it manually, so you can't copy&paste their action for your use
(+ Brew allows you to install Mac .app bundles in a custom folder)
Security: + Ports has a slightly better security model (folder persmissions are better though I think it only matters for multi-user machines, so mostly no relevant; it also does some sandboxing on install via a specially created user), the downside is annoying sudo, but you can remove the need for sudo for some less sensitive ops like update/uninstall to cut down on the annoyance
Space: + Brew. Both waste it with their poor package repository architecture, but with Brew you can at least delete the repo after the first install and use their API to download updates. With Ports you can't do that, moreover it duplicates its registry (one for sync, uncompressed, another for local use)
Docs: + Brew, also random Google/SO answers are less likely to be outdated
UI: + Brew. Has more info (like size), better formatted
> Space: + Brew. Both waste it with their poor package repository architecture, but with Brew you can at least delete the repo after the first install and use their API to download updates.
BTW, with this release the Homebrew uses the API by default and doesn't clone the repos unless necessary.
I did recently, when I switched from an old computer to a new Apple Silicon Mac. It was pretty easy! I was already familiar with it because I used homebrew-cask for application installs, and used to help maintain that project. The most difficult part was really just redoing location of library paths for Perl and the such.
I like brew because it’s easier to audit, faster to fix issues, and tends to update first. Years ago, macports just had so much more, but that’s become less of an issue over the years, for me anyway. Getting away from sudo is always a plus. MacPorts probably(?) is still better for very old machines, though, both in terms of speed and availability.
I switched from Homebrew to Macports, although I may switch back.
Basically, Homebrew will completely crap out on you if you are ever more than two macOS versions out of date. The brew people simply don't keep the older bottles around for those versions of macOS. I think there's a grace period of like one extra version, but eventually they will delete it. Once that happens, your system is hosed if you ever need to install any new packages from Homebrew ever again. You will only be able to install from source, and it's a tossup if that will work.
This is a fairly controversial Homebrew policy and lots of people have complained about it, and there's lots of rhetoric on both sides. My stance: while it's a good idea in general to stay up to date, if you are the kind that likes to keep old legacy machines around to do a few things here and there, you should know your Homebrew installation will eventually break if you don't keep updating the OS. You will eventually not want to do when the system gets old enough, and at that point Homebrew will be a mess.
I'm not interested in the debate as I get both sides, particularly involving security concerns. My experience: simply put, Homebrew's policy will cause you to have to sideline your system, or at least work around this really tedious roadblock, while it still has a good amount of life in it. I wish they kept old bottles around a few years longer, because 2-3 years is not long enough.
So I said that on my current system, which I do keep current, I'm going to not use Homebrew at all. I figured I'd use Macports, since one of the big selling points is that it works on older versions, so I won't eventually run into this problem five years from now. So I did.
The main problem is that there just aren't anywhere near as many packages as there are on Homebrew. Homebrew has become a standard for all kinds of stuff, and if there's ever a package you want on Homebrew, and it's not on Macports, what do you do? You will run into this when using Macports all the time. I've also had issues using Macports with M1; I don't remember the details but there was some weirdness I ran into one point having to configure it to set the architecture correctly on some package I was trying to install. I'm not quite sure how that compares to brew, though, since I haven't tried brew on M1.
So the net result of all of this is, I have a bunch of installation setup scripts that I moved from Homebrew to Macports, and then half of the packages just weren't on Macports, so I had to write scripts to just download those things from elsewhere - GitHub, website installers, whatever.
So now I'm debating moving back to brew. On the one hand, it just has everything, and Macports doesn't. On the other hand, it will eventually break, and Macports isn't that bad - has basic terminal commands I need and so on. I'm on the fence. If there were some user-maintained repository of legacy bottles for brew I'd move back to that.
Portfiles are definitely a little more outré than brew's Ruby, but I've found it's not too hard to make one for a tool by starting from another similar existing port. You get the contents of the example one with `port cat $existing_tool`, tweak it, and then add it to a local port repo: https://guide.macports.org/chunked/development.local-reposit... And then you can just `sudo port install $new_tool`
