5 ms·

As a MacPorts users (generally light-weight, just a few things here and there): Has anyone gone from MP to HB, or vice versa? Why did you switch from one to th

As a MacPorts users (generally light-weight, just a few things here and there): Has anyone gone from MP to HB, or vice versa? Why did you switch from one to the other (and perhaps back again)? What did you find as the pros/cons of each?

isityettime 3d ago
I use basically every general-purpose package manager available on macOS simultaneously in a kind of tiered hierarchy of preference. Homebrew's best differentiated strength imo is the whole Cask subsystem, which basically automates GUI app installs via "first-party" artifacts like .dmg and .pkg files. That's what I still sometimes use it for even though I have other package managers available, including MacPorts, that I prefer for most other things. The ordering goes something like the following: Nix > pkgsrc > MacPorts > Homebrew > mas (CLI frontend for the App Store). Each kinda has its niche. Nix is just generally preferable for me, and it covers all of my needs 99% of the time. It also happens to be pretty fast in terms of actual installation even if evaluating the Nix code can be slow for complex projects. For proper development toolchains, it's all Nix all the time. Those are per-project rather than global, and what can't be managed by Nix isn't managed at all. Nix is this an overriding constraint there, which has never really been a problem for me. Pkgsrc is good for development tools and terminal apps, but Nix is generally even better for those, so for me it's just an escape hatch in case something is broken or missing in Nixpkgs and I'm too lazy to fix it, or I genuinely want some library installed with its headers findable globally (rare, because that's mostly bad practice imo). Also good if I want a backup copy of an exotic shell or something in case I want to rm -rf /nix and not be forced back into Bash or zsh, which is nice when I'm working on my macOS bootstrap scripts. On macOS, everything you install via Pkgsrc will be a binary install, so it's relatively fast and its performance is relatively predictable. MacPorts is broadly useful so it's useful for the same things as Pkgsrc, but it's also better at providing GUI Mac apps, built from source. For a while I got Emacs here when Emacs in Nixpkgs had a problem building with native compilation support, for example. Also good for my macOS bootstrap scripts since they're written in literate style in Org mode; it can be nice to have a working Emacs to dump them to disk with even without Nix if I'm iterating on them. MacPorts often ends up building stuff from source on my system, which can be slow, but I don't care because I have very little installed via MacPorts. Homebrew historically didn't feel "safe" for me for development dependencies for various reasons. Before sandboxing support, running and installing and managing things as your own user felt especially unsafe from a security perspective. Now it's a lot better, but it still feels wrong to have global-ish prefixes owned by a particular user. The aggressive in-place upgrades also feel quite brittle for development dependencies, but to some extent that's true of anything that's not project-local. I also don't like that installing GUI apps with Homebrew can end up putting binaries related to their dependencies and not needed at runtime into my PATH— that feels way messier than what I get with Nix. It can also historically be very slow for what it does, but if you're using it in the recommended way, you don't often have to build from source so you can still expect a faster experience than with MacPorts even though both nominally support binary packages. All that said, Homebrew shines when it comes to extremely broad support for arbitrary Mac apps, often including proprietary ones, and support for the arbitrary range of installation procedures that macOS app developers expect you to use. It's also very good in terms of freshness for macOS packages. Nix is competitive in that respect, but none of the others remotely are. The stuff I don't like about where Homebrew puts things and the filesystem permissions are also fixable if you use a custom prefix. That's officially unsupported and means you can't use "bottles" (i.e., you'll need to build packages that aren't "casks" from source), but it works fine and has been totally stable for many years. If you understand some basic Unix norms and how to compile software from source, you should feel comfortable doing it. I also like to keep Homebrew's bin/ paths off my PATH, and selectively symlink or wrap binaries installed via Homebrew back to ~/.local/bin by hand. That way I can install whatever I want via Homebrew without worrying about it getting unexpectedly involved in my development processes or command-line environment. Because Homebrew has historically been so slow for me, I've tried to install as little with it as possible, which means installing even some Mac GUI apps via Nix. That's kind of a pain because if you want Spotlight to pick them up, you need little trampoline wrapper apps because it won't register symlinks into the Nix store. And when Nixpkgs' selection is lacking, you can extend it with brew-nix, which uses Homebrew's JSON API to automatically generate Nix packages. They work, but some apps just can't do everything they're designed to from the Nix store due to macOS limitations/security policies, so you have to kind of figure out which you can install via Nix yourself. It's extra machinery, and so if Homebrew is faster enough now I may look forward to dropping it and just using Homebrew as my first choice for all GUI apps. The App Store sucks, needless to say, not least of all because it requires an active login to a large tech company. I only use it for VPN apps or security software where Apple forces me to. I don't recommend my setup to people for whom package managers aren't a first-class interest, but it is perfectly stable and it's unlikely to get you into trouble. I think most people would be served well by combininations of two package managers, of one of two forms: Nix + an escape hatch or Homebrew + a development toolchain manager. For people who like macOS' app installation procedures: Nix + pkgsrc For people who like Nix but want a disciplined escape hatch: Nix + MacPorts For people who like Nix and want absolute coverage: Nix + Homebrew For people who don't really care about how their package manager works but are developers: Homebrew + mise or Homebrew + Nix For non-developers who just want an automated/centralized way to install software aside from the App Store: Homebrew (and probably especially the GUI) I think the main thing for me is just that no one should have free-floating, ambient development dependencies. You shouldn't have some software project that depends on what version of Python is on your PATH or what packages from PyPI are globally installed via pip or whatever. You shouldn't be manually building unoconv or pandoc or something against some LibreOffice headers that live in /usr/local or /opt/local or anywhere like that. Ideally, shouldn't be doing `make install` anywhere— if you need to compile something for your own use, compile it by writing a package (or having an LLM write it, you lazy bum). If you observe that kind of basic package management hygiene, "switching" is largely trivial and doesn't involve any manual cleanup or fixing. And if you spend a few minutes thinking about a preference order that you like and configure your PATH accordingly, all of these package managers can coexist so that you can "switch" gradually, at your leisure.
deleted 3d ago
[deleted]
ihuman 3d ago
I switched from macports to homebrew a decade ago. I needed the lastest version of a program, and I found homebrew updated formulas faster than macports did
apothegm 3d ago
I switched from MP to Homebrew over a decade ago. At the time, Homebrew was less finicky and better at resolving dependency conflicts. It was a lot easier to get a system running MacPorts into a an irretrievably borked state. Not long after, Homebrew install instructions became ubiquitous, whereas with MacPorts it seemed like you always had to figure it out for yourself — if the package was even available, which it more often wasn’t. Haven’t used MacPorts since. Has it gotten any better at those things?
ryandrake 3d ago
I switched from Homebrew to MacPorts a few years ago because of Homebrew's aggressive dropping of macOS versions they consider "too old." Even in the top-comment announcement here[1] they are making sure to include that they are removing support, as if they're proud of it! MacPorts generally doesn't care what version of macOS you run, so here I am. I'll probably never go back to Homebrew. MP is great! 1: https://news.ycombinator.com/item?id=49681546 https://news.ycombinator.com/item?id=49681546

isityettime 3d ago

I use basically every general-purpose package manager available on macOS simultaneously in a kind of tiered hierarchy of preference. Homebrew's best differentiated strength imo is the whole Cask subsystem, which basically automates GUI app installs via "first-party" artifacts like .dmg and .pkg files. That's what I still sometimes use it for even though I have other package managers available, including MacPorts, that I prefer for most other things. The ordering goes something like the following: Nix > pkgsrc > MacPorts > Homebrew > mas (CLI frontend for the App Store). Each kinda has its niche. Nix is just generally preferable for me, and it covers all of my needs 99% of the time. It also happens to be pretty fast in terms of actual installation even if evaluating the Nix code can be slow for complex projects. For proper development toolchains, it's all Nix all the time. Those are per-project rather than global, and what can't be managed by Nix isn't managed at all. Nix is this an overriding constraint there, which has never really been a problem for me. Pkgsrc is good for development tools and terminal apps, but Nix is generally even better for those, so for me it's just an escape hatch in case something is broken or missing in Nixpkgs and I'm too lazy to fix it, or I genuinely want some library installed with its headers findable globally (rare, because that's mostly bad practice imo). Also good if I want a backup copy of an exotic shell or something in case I want to rm -rf /nix and not be forced back into Bash or zsh, which is nice when I'm working on my macOS bootstrap scripts. On macOS, everything you install via Pkgsrc will be a binary install, so it's relatively fast and its performance is relatively predictable. MacPorts is broadly useful so it's useful for the same things as Pkgsrc, but it's also better at providing GUI Mac apps, built from source. For a while I got Emacs here when Emacs in Nixpkgs had a problem building with native compilation support, for example. Also good for my macOS bootstrap scripts since they're written in literate style in Org mode; it can be nice to have a working Emacs to dump them to disk with even without Nix if I'm iterating on them. MacPorts often ends up building stuff from source on my system, which can be slow, but I don't care because I have very little installed via MacPorts. Homebrew historically didn't feel "safe" for me for development dependencies for various reasons. Before sandboxing support, running and installing and managing things as your own user felt especially unsafe from a security perspective. Now it's a lot better, but it still feels wrong to have global-ish prefixes owned by a particular user. The aggressive in-place upgrades also feel quite brittle for development dependencies, but to some extent that's true of anything that's not project-local. I also don't like that installing GUI apps with Homebrew can end up putting binaries related to their dependencies and not needed at runtime into my PATH— that feels way messier than what I get with Nix. It can also historically be very slow for what it does, but if you're using it in the recommended way, you don't often have to build from source so you can still expect a faster experience than with MacPorts even though both nominally support binary packages. All that said, Homebrew shines when it comes to extremely broad support for arbitrary Mac apps, often including proprietary ones, and support for the arbitrary range of installation procedures that macOS app developers expect you to use. It's also very good in terms of freshness for macOS packages. Nix is competitive in that respect, but none of the others remotely are. The stuff I don't like about where Homebrew puts things and the filesystem permissions are also fixable if you use a custom prefix. That's officially unsupported and means you can't use "bottles" (i.e., you'll need to build packages that aren't "casks" from source), but it works fine and has been totally stable for many years. If you understand some basic Unix norms and how to compile software from source, you should feel comfortable doing it. I also like to keep Homebrew's bin/ paths off my PATH, and selectively symlink or wrap binaries installed via Homebrew back to ~/.local/bin by hand. That way I can install whatever I want via Homebrew without worrying about it getting unexpectedly involved in my development processes or command-line environment. Because Homebrew has historically been so slow for me, I've tried to install as little with it as possible, which means installing even some Mac GUI apps via Nix. That's kind of a pain because if you want Spotlight to pick them up, you need little trampoline wrapper apps because it won't register symlinks into the Nix store. And when Nixpkgs' selection is lacking, you can extend it with brew-nix, which uses Homebrew's JSON API to automatically generate Nix packages. They work, but some apps just can't do everything they're designed to from the Nix store due to macOS limitations/security policies, so you have to kind of figure out which you can install via Nix yourself. It's extra machinery, and so if Homebrew is faster enough now I may look forward to dropping it and just using Homebrew as my first choice for all GUI apps. The App Store sucks, needless to say, not least of all because it requires an active login to a large tech company. I only use it for VPN apps or security software where Apple forces me to. I don't recommend my setup to people for whom package managers aren't a first-class interest, but it is perfectly stable and it's unlikely to get you into trouble. I think most people would be served well by combininations of two package managers, of one of two forms: Nix + an escape hatch or Homebrew + a development toolchain manager. For people who like macOS' app installation procedures: Nix + pkgsrc For people who like Nix but want a disciplined escape hatch: Nix + MacPorts For people who like Nix and want absolute coverage: Nix + Homebrew For people who don't really care about how their package manager works but are developers: Homebrew + mise or Homebrew + Nix For non-developers who just want an automated/centralized way to install software aside from the App Store: Homebrew (and probably especially the GUI) I think the main thing for me is just that no one should have free-floating, ambient development dependencies. You shouldn't have some software project that depends on what version of Python is on your PATH or what packages from PyPI are globally installed via pip or whatever. You shouldn't be manually building unoconv or pandoc or something against some LibreOffice headers that live in /usr/local or /opt/local or anywhere like that. Ideally, shouldn't be doing `make install` anywhere— if you need to compile something for your own use, compile it by writing a package (or having an LLM write it, you lazy bum). If you observe that kind of basic package management hygiene, "switching" is largely trivial and doesn't involve any manual cleanup or fixing. And if you spend a few minutes thinking about a preference order that you like and configure your PATH accordingly, all of these package managers can coexist so that you can "switch" gradually, at your leisure.

deleted 3d ago

[deleted]

ihuman 3d ago

I switched from macports to homebrew a decade ago. I needed the lastest version of a program, and I found homebrew updated formulas faster than macports did

apothegm 3d ago

I switched from MP to Homebrew over a decade ago. At the time, Homebrew was less finicky and better at resolving dependency conflicts. It was a lot easier to get a system running MacPorts into a an irretrievably borked state. Not long after, Homebrew install instructions became ubiquitous, whereas with MacPorts it seemed like you always had to figure it out for yourself — if the package was even available, which it more often wasn’t. Haven’t used MacPorts since. Has it gotten any better at those things?

ryandrake 3d ago

I switched from Homebrew to MacPorts a few years ago because of Homebrew's aggressive dropping of macOS versions they consider "too old." Even in the top-comment announcement here[1] they are making sure to include that they are removing support, as if they're proud of it! MacPorts generally doesn't care what version of macOS you run, so here I am. I'll probably never go back to Homebrew. MP is great! 1: https://news.ycombinator.com/item?id=49681546 https://news.ycombinator.com/item?id=49681546