In my experience, the Homebrew package registry is bigger and fresher than MacPorts. It also supports GUI apps, and it's much faster because it uses binaries by default. I suggest MacPorts work on catching up in these ways if they want to compete with Homebrew. I am not a fan of Homebrew's design but I'm a very pragmatic person and I don't have time to be ideological about my package manager.
> the Homebrew package registry is bigger and fresher than MacPorts
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.
> 5901 packages in homebrew-core versus about 11000 ports in MacPorts (not counting subports).
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.
> 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.
One interface to two different package managers is preferable to two interfaces to two different package managers. My experience with Homebrew is that it has what I need more often than MacPorts does, this is why I continue to use it.
They were probably going by the Repology stats, which use a cross-distro notion of 'projects' rather than individual packages, which is why their figure was given as excluding subports
