Regarding MacPorts:
> MacPorts distributes source code that is compiled on install, so Macports is generally much slower to install packages. Macports installs packages under “/opt/local”. Macports uses root, which can lead to users goofing up their system or workplace policy issues
Sounds horrifying
At this point I only use Homebrew for casks and Nix for everything else on macOS, which is far more up to date, reproducible, and cross-platform.
When you do that, do you also need to compile the applications during installation…? (E.g. stuff written in Rust/C/C++)
Do you need to edit the “recipes” a lot or do they generally Just Work?
Nix is very powerful; there's a steep learning curve the more of its ecosystem you use. If "declarative", "generational", "immutable" are all words you like, it's worth looking into.
It's one of the best ways to be able to get a consistent set of tools (and versions of) across macOS/Linux.
> When you do that, do you also need to compile the applications during installation…? (E.g. stuff written in Rust/C/C++)
My experience using Nixpkgs with macOS was that most stuff downloaded from the cache. I would run into a few cache-misses where Nix would fetch & compile the source. (e.g. KeePassXC .. although maybe it wasn't cached because other users would install programs like that from casks).
> Do you need to edit the “recipes” a lot or do they generally Just Work?
Mostly it works. The caveats:
- I have run into a case where some test failed because of path length limits(?). I worked around that by skipping the test.
- I'd guess the order of popularity of community usage is "NixOS > other Linux > macOS > other". Some packages might be able to work on macOS, but either have metadata marked as linux-only, or don't take care of (maybe) macOS specific needs. (e.g. It's been fixed, and the workaround wasn't difficult before that, but I'd run into this https://github.com/NixOS/nixpkgs/issues/56348).
- Nix is weird; so, sometimes when it's not doing what you want, it can be difficult to figure out what it is you have to do. (So, you can fall-back and use homebrew or whatever).
If it's in Nixpkgs and it builds, then you skip the building step entirely and fetch from cache.
> Do you need to edit the “recipes” a lot or do they generally Just Work?
They generally just work.[0] If you do need to edit the package expressions it's usually to switch versions or to a fork, IME.
[0] https://hydra.nixos.org/jobset/nixpkgs/nixpkgs-21.11-darwin
Cachix is a proprietary SaaS alternative to Hydra's binary caching component. It's free to use for F/OSS, and it's much easier to set up than Hydra, so plugging Cachix in to a generic CI system like Travis or GitHub actions is a popular choice for open-source projects in the Nix community.
It's straightforward enough that the software devs I work with consider it "painless" to use.
asdf describes itself as "asdf is a CLI tool that can manage multiple language runtime versions on a per-project basis. It is like gvm, nvm, rbenv & pyenv (and more) all in one!"
I use Homebrew for general purpose niceties like starship, fzf, and casks.
Project deps are managed with asdf.
The “right answer” may in fact be Nix however. I just haven’t fully grokked it yet.
Since 2009. There is no package manager younger. But it sure has a lot of hype.
> I've never seen a better alternative for macOS
Because you've never looked. Every other package manager available on macOS is better than Homebrew. pkgsrc. Nix. Fink. All of them are better. Homebrew is dead last in features and stability. After using Homebrew for only a short time, you'll have a mess on your file system. Good luck cleaning it up.
MacPorts will install pre-built binaries with the -b option, if you want. But building from source is superior. It's called rolling your own, because what you build is yours and yours alone, and it is more secure, allowing review of the code, has the advantage of customizing with specific variants and deeper customizations, and allows installing the most recent version of the code. With binary installs, your're stuck with whatever you get. Also, MacPorts is more compatible, will install and build from Tiger on up, anc works for all users on the system with sudo access. Homebrew abandons older systems rapidly, and only works for one user. But the most obnoxious thing about Homebrew is what it does to /usr/local, which is to say it fubars the directory and everything that lives there.
Been using Homebrew for a decade and haven’t had serious problems with it in a very long time. I do use asdf for versioning language runtimes though. I’m not saying it doesn’t have these problems, just that it’s possible to use without running into them, which is why I haven’t felt compelled to switch.
> But building from source is superior.
Not if you value your time. Also Homebrew supports it with --build-from-source, so this is really just a question of defaults. Homebrew values my time.
Try using from another user account
Again, since you don't seem to be reading what I'm writing:
The primary reason I use Homebrew is not because I think it has a superior design for package management or because it has the absolute greatest number of packages but because I have never once encountered a dependency that was not in its registry. It always has what I need. The same is not true of MacPorts. It is immaterial to me how many MacPorts packages exist that I don't need, because it doesn't always have the ones I do need.
Here's a good example that I just found randomly right now:
MacPorts Erlang: version 23.1, from September 23, 2020 (https://ports.macports.org/port/erlang/).
Homebrew Erlang: 24.2, from December 15, 2021 (https://formulae.brew.sh/formula/erlang).
Yes, when encountering something like this, I could take the time to update the port definition. Or I could just install the version that already exists in Homebrew and get on with things. Can you understand why I would choose the latter in the absence of a need for multi-user functionality or any other real issues with brew in day-to-day usage?
This is the primary reason for using a package manager. What you are claiming is extraordinary, that MacPorts has some number of ports that can't build because of missing dependencies. What you are claiming is MacPorts is hopelessly broken, which ironically is precisely the way I feel about Homebrew, that while using it for a handful of ports may be fine, but that it plays fast and loose with UNIX standards and ultimately breaks down. I think it is far more likely that you came across a problem either due to the state of your system, or that there was an actual defect (which is ordinary, and that likely as not had been fixed before long), and you didn't understand and didn't want to bother with it. What I suspect is that you had one single problem somewhere and incorrectly believe, for reasons beyond understanding, a fallacious and sweeping generalization that MacPorts pervasively has missing dependencies. That's what I think because your claim is borderline absurd.
But if you're happy with Homebrew, more power to you. As I stated, I disagree, and personally find Homebrew not merely superfluous but broken fundamentally for it's underlying ideology, which is to ignore the standards on the systems it is targeting, and if not for it's constant desperate and ravenous marketing, and being propped up by unrelated projects, would have died years ago, but the momentum of its hype keeps it dragging its ugly mess along without actually moving forward. I could be mistaken, but that's how I see it.
> Here's a good example that I just found randomly right now: MacPorts Erlang: version 23.1, from September 23, 2020 (https://ports.macports.org/port/erlang/). Homebrew Erlang: 24.2, from December 15, 2021 (https://formulae.brew.sh/formula/erlang).
No this is not in the least what you were specifying. Now your newly introduced complaint is not that dependencies are missing, but that the package is not at the bleeding edge, because you need your packages at the bleeding edge in your production for unnamed reasons. You are among those that have apparently not yet been burned by applying every update the moment you see it, have not yet seen your production grind to a halt because of your itchy trigger finger. But it is inevitable if you're applying updates without consideration of the fact that the only possible reasons for applying an update to production (as opposed to development) is 1) new features that are essential to your production, 2) bug fixes that repair your production, and/or 3) security patches which are relevant to your production or system. Without consideration of these, that is, if these considerations make no difference to your production or system, you are applying updates without reason. I never let it get this far with Homebrew, so I don't have experience with rolling back updates or upgrades with it. But MacPorts takes this into consideration, and the method for doing so is well documented in the online manual and proscribed by its listserv members generously if the manual was ignored.
Let's break this down.
> Macports is generally much slower to install packages
MacPorts and Homebrew are both source-based package managers. Distributing source code to be compiled on install is the basic design of both. And both also have binary caches. I think compared to the size of each package collection, Homebrew's binary cache is more complete, so it might save you some time sometimes.
(As package managers go, though, Homebrew is extremely slow.)
> Macports installs packages under “/opt/local”
This is much better behavior than taking over /usr/local, which is generally for packages you install manually. It's much more portable and much less prone to compatibility problems.
> Macports uses root, which can lead to users goofing up their system or workplace policy issues
Homebrew uses root and it just hides from you that it uses root by giving ownership of /usr/local to your particular user, which constitutes a system policy issue. It's a security problem and it's also just a disgusting thing to do on a nominally multi-user operating system.
The only one of these issues where Homebrew wins is with the binary cache size (which has apparently come at the cost of reducing customizability for many Homebrew packages, if the comments of longtime Homebrew users on GitHub and HN are to be believed).
Isn't using `/usr/local` pretty standard for BSDs? I remember that on FreeBSD the package manager installs things there, and I _think_ NetBSD and OpenBSD might also, but it's been so long that I've played around with them that I can't remember for sure.
While ports packages are always considered 'optional', they are sometimes first-party (as opposed to 'foreign') in the sense that they're made by the same community of developers as the base system, and they are universally expected to be the main package manager on that particular OS. I think usage of /usr/local as an install prefix is more typical for ports systems that are 'first-party' in this sense.
When Homebrew was created, MacPorts already used /usr/local, and Homebrew's choice to do the same made them incompatible with one another. /usr/local is also directly used by language-specific package managers for global package installs by default, which is another potential source of conflict.
Because /usr/local is on a lot of default search paths, it's more likely that libraries installed there will be picked up by default by random programs on the system (both at build time and at runtime). This is somewhat convenient, especially if you want your package manager to modify the behavior of the underlying base system. But it's also less portable, less predictable, and more presumptuous in that it is more likely to cause conflicts with other tools (and thus assumes/asserts that you won't use them). For these reasons, most ports systems that target foreign operating systems (e.g., Pkgsrc, MacPorts, Ravenports, Gentoo Prefix, and, oddly enough, Linuxbrew) don't target or recommend /usr/local as the default install prefix.
It's not spam, but it is annoying if you're trying to use `brew doctor` in an automated process.
[1]: https://saagarjha.com/blog/2019/04/26/thoughts-on-macos-pack...
I'm quite enjoying Nix as a *nix + mac package manages. Plus using direnv really makes things a breeze. Although Nix has a __very__ steep learning curve... I still recommend it greatly!
https://www.tecmint.com/nix-package-manager-for-linux/
There may be bugs with packages though, so I use it for what works for me. Not when it breaks with local dynamic libraries. It's a nice addition to get more recent packages than the distro offers.
Guix can be used as additional package manager as well.
NixOS (the distro) is steep though, like driving madly along a cliff steep. Guix even more so but with less speed.
I've found these three options to be very valuable:
export HOMEBREW_UPDATE_REPORT_ONLY_INSTALLED=1 # only list updates to installed software
export HOMEBREW_NO_ANALYTICS=1
export HOMEBREW_NO_AUTO_UPDATE=1False. Binaries, built from source, are used by default.