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?
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.
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
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).
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.
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).
It's not spam, but it is annoying if you're trying to use `brew doctor` in an automated process.
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.
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.
False. Binaries, built from source, are used by default.
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=1[1]: https://saagarjha.com/blog/2019/04/26/thoughts-on-macos-pack...
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.
Me too. It embeds Google spyware without consent, sending a unique identifier from your machine every time you use it.
It's disturbing seeing people say "just run `brew install $PACKAGE`" where $PACKAGE is privacy or local-first software without including the requisite `brew analytics off` on the line above it.
If you would be so kind to elaborate? I’m curious what the pain points or issues are with homebrew.
I personally can't use it anymore now that my MacOS version (Mojave) is not supported so everything has to build from source and Rust fails.
Ask HN: Best Alternative to Homebrew in 2021? https://news.ycombinator.com/item?id=29079096
This is pretty interesting, that Homebrew abandons recent systems. I am running MacPorts on Mojave with no issues (yet). However, I am strongly considering going back to High Sierra for it's ability to build 32-bit packages, which Mojave won't do (though it will still run 32-bit applications with a warning). The only thing that keeps me from doing so immediately is that I have macOS install exhaustion. I'm a little beat up because I am doing custom macOS installs, and it takes a little effort to prevent the installer from installing all the crap I don't want. The easier way to do it is just to let it install, then remove it. I'm a little something that I prefer to go the other route, and I'm not aware of anyone else fighting the default system install to assist. I have no doubt that MacPorts runs flawlessly on High Sierra, because I have it running flawlessly on Mountain Lion, and I have a functional but frozen install of MacPorts on Snow Leopard, but I am aware there are others that have live and functional MacPorts running on Snow Leopard with a minimal amount of effort, and I'm pretty sure the same is true of Leopard, Tiger and Jaguar, though the number of users gets smaller the further back we go. It can not be overstated how awesome that is, that no system version is completely left behind. This exposes that MacPorts has some seriously resiliant development.
The Homebrew package registry is fresher but not bigger than MacPorts. 5901 packages in homebrew-core versus about 11000 ports in MacPorts (not counting subports).
Package freshness depends on contributions. A bigger collection is inherently harder to maintain, yet MacPorts has fewer active contributors than Homebrew.
> It also supports GUI apps
MacPorts doesn't have a separate cask-like feature, but there are some GUI apps in the aqua category, most of which are built from source with binary cache.
If you need to manage proprietary and/or binary GUI apps with a package manager, you could still use Homebrew casks for that and MacPorts for everything else.
Good to know that it is still actually bigger, but that’s really only relevant to me if it’s a superset of Homebrew’s registry, and in the past I have found packages I needed that were in Homebrew but not MacPorts. If I had to guess I would bet MacPorts has a lot of older stuff in it.
> Package freshness depends on contributions.
Of course, I understand this. It’s the main reason I have to use Homebrew. I don’t want to have to maintain my own packages.
> If you need to manage proprietary and/or binary GUI apps with a package manager, you could still use Homebrew casks for that and MacPorts for everything else.
This is what I mean about being ideological. What benefit do I get from installing two different package managers when one would suffice? It’s definitely not enough to merit doing so.
If you use both Homebrew proper and Homebrew casks, you're already using two package managers. The casks implementation and the formulae implementation have basically nothing to do with each other. They use completely different repositories of 'build' recipes, and they install completely different kinds of packages distributed in completely different formats to completely different places. The installation procedure and the frontend are the only things the two package managers share. The unification of the latter is a thin veneer, since there are various flags and options which apply exclusively to casks rather than formulae or vice-versa.
On the other hand, Homebrew's cask subsystem is basically just a fetcher and runner for installers that already bundle all the dependencies of the apps they install, and in that sense it's not really a package manager.
> Good to know that it is still actually bigger, but that’s really only relevant to me if it’s a superset of Homebrew’s registry,
Pretty much every package repository has some packages in it that are unique to that repository, and so pretty much no package repository is a superset of any other (with the possible exception of downstream forks, depending on how you count things). If you actually apply this standard strictly to any distribution of software, it will almost always mean you can't switch to any other.
> when one would suffice?
For a range of use cases, Homebrew is already insufficient. For example, any program packaged for Homebrew which depends on a Perl library requires you to globally install that library manually via OPAM. Homebrew does nothing at all to help you manage that entire class of dependency, and leaves it to you to install another package manager to do it.
MacPorts has 28,082 active ports.[1] I'm not sure if that includes subports.
Linux OS package managers are, almost by necessity, full of outdated packages which are not the versions I want to use for day-to-day CLI applications. Snaps, Flatpaks and AppImages all have their own downsides due to half-baked isolation goals and the associated usability compromises. Language-specific package managers are a mixed bag, but too narrow in scope when thinking about usage of tools rather than development based on libraries. Maybe Nix or the Arch AUR are a better option, but they come with a learning curve and/or stability compromise. I don't care how the packages are arranged on my Mac; the system is too locked down for me to really have the level of control I'd like anyway, so better to just accept the usability advantages and get on withy life.
This is a valuable perspective. I wonder how much macOS primes users in general to value usability over other dimensions of good design.
(I also wonder how much better a time I'd have on macOS if I adopted this attitude.)
It is the de facto default package manager as most installation instructions default to it if they mention a package manager on MacOS
> It is a recent development
1. It's been around for 12 years already
2. Being more recent doesn't preclude it from being a de facto default
> Why the constant advertisement for adoption
It's not "constant advertisement". This is what being the de facto default means: people are using the de facto default and not something that you perceive as the default
It's not a package manager
> Homebrew is worse than forgoing package management and just using git
So you're using AppStore as your package manager?
> Homebrew is pure hype, and without the hype, it has nothing.
Ah yes, the well-known decade-old hype that everyone keeps advertising.
If it installs, upgrades, configures and removes programs, App Store is indeed one of these. Apple invented package managers in 2008 (LOL).
So. Do you use it to install all your software? Oh wait. You don't: "Give me MacPorts any day of the week and twice on Sunday."
So, why aren't you using App Store?
The various tools included in MacOS are often old or BSD versions instead of GNU tools. There's lots of gotchas when writing scripts on MacOS that will run as part of a Linux build pipeline.
Yes I am referring to the certified POSIX userspace on macOS.
Portable UNIX software should use POSIX anyway not GNUisms.
It really does!
Homebrew was written to take some shortcuts to reduce compilation time vs. MacPorts at that time. It was also written to be simpler to hack on and package for, since the author found MacPorts harder to work with than he'd have liked.
I think it takes the metaphor too far but I've seen Homebrew fans praise it as making things like repo management accessible to them when they started using Homebrew without prior experience with other package managers. So maybe it's useful.