LOL Actually one my hopeful future additions is to maintain (or use discovery) a list of name-to-repo mappings.
ie. I would love for users to be able to just do:
$ bingo install hugo
... installing github.com/gohugoio/hugo
I don't really want the concept of any project _owning_ a name, so in the cases where multiple projects were mapped/discovered for a given name, we'd want to ask the user which one they wanted to install.
1: This needs a copy-pastable 1-5 lines at the top of the readme for installing it (which installs the binary, and adds it to your PATH, and appends to your .bashrc or .zshrc or whatever).
2: Please support metapackages, so that I can publish a list of all packages I want/use and "bingo install" that.
3: Consider a "bingo selfinstall" command that appropriately detects .zshrc/.bashrc/whatever and appends the magic PATH-munging. (cf "nextdns install")
4: That is an excellent name for a utility. (Much better than this cargo/crate/gem/bundle/beer/cask/tap crap.)
Greetings! Thanks a lot for taking the time to look at Bingo.
1: re: copy-paste install script: I'll definitely grind on this and see what we can do. Bingo requires my Run[1] package, which itself is written in go and can be installed via `go install github.com/TekWizely/run` -- Additionally, once you have Bingo installed, you can use IT to re-install Run and then manage your Run installation via Bingo itself ! A self-running install script for Bingo that installs a temporary version of Run, then installs Bingo, then uses Bingo to install a permanent version of Run would actually be quite clever !
2: re: metapackages: Bingo's goal is to be a useful wrapper on top of Go's built-in, and highly useful, install feature. Go's auto compile+install features are already getting pretty complex (ie code generation, specifying tags, etc)... The fact that you can download and install hugo with `--tags extended` from the command line is pretty sweet. That said, I would say any additional support (ie metapackages) might first start as a request against go install proper -- That said, it might be a nice addition to maybe fetch some kind of `go.install` file that contains basic steps for installing a complex package. If it was going to be a non-sanctioned idea, I would still want the format of the file/spec to stand on its own and be useful outside of Bingo.
4: Graci ! I am quite pleased with myself for the name - BTW: The idea for the tool came first. I then brainstormed the name ...
Thanks again and please lemme know if you have any further comments/questions! If nothing else please consider opening Issues for these ideas to help me keep track of them :)
Looking at bingo’s features, you already get most of them for free in Nix, such as multiple package versions, isolation and naming binaries to what you want. But the key difference is that Nix’s dependency specification is exact, not nominal like in bingo (so two packages of the same version and name but slightly different dependencies wouldn’t be confused in Nix.)
I recently packaged fq (written in Go) in Nixpkgs[0] and it was a breeze. You just have to specify the vendor and source hashes (which can be done automatically), and you get reproducibility for free (at least in the build environment.)
What is the proper automated way to get vendorSha256? Currently I always set it to lib.fakeSha256 first, then run the build and obtain the hash from the error message.
To speed things up a little, you can evaluate exactly what you need in the REPL to trigger the error. You can even paste the Nix expression with the fake sha in and it'll be quicker than evaluating your entire build.
There's probably a CLI out there that fetches it a la nix-prefetch-url/git/etc
When a name fits a project so well, you have to wonder whether they thought of the name first, and that dictated the project concept. Either way, awesome.
Bingo is basically a wrapper over `go install` that makes it easier to manage the binary after installation. ABI and Distro etc issues are resolved however Go resolves them internally.
What I learned from this article is that it's now a good thing when the package manager you use depends on which compiler was used to compile the program you are installing.
I mean yeah? Cargo works the same way. You have to bootstrap with something and avoiding a dependency outside your language ecosystem is a good way to ensure that the lifetime of your package manager is as long as the language it supports.
For single language projects that seems like a clear choice. I’m more curious about multi-language projects…
For example a project might mix Java, JavaScript, and Python. Should the project use all three package managers? When should the operating system package managers (rpm, yum) be used? What package manager is a good choice for languages without first-class package managers (like Ada or Fortran)? When is a developer portal package manager, like Backstage.io description format (https://backstage.io/docs/features/software-catalog/descript...), the way to go?
This is my currently preferred stack. Currently in my second year of working on a 25k LOC project in this stack and it has scaled up to meet those demands.
I sure wish Homebrew would cease being cited as a standard or defacto package manager for macOS. It is a recent development, leaves so very much to be desired while also leaving a mess, boxes permissions, takes its annoying metaphor too far and has no advantage over any other package manager. Why the constant advertisement for adoption? Give me MacPorts any day of the week and twice on Sunday.
Homebrew has been around for a long time. I've never seen a better alternative for macOS, do you think you could mention any of them?
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
Homebrew has been pretty poor IME. It is not possible to pin the homebrew repository per project, dependency confusion happens a lot (try installing different versions of core libraries at the same time), the way it messes with macOS file system permissions in /usr/local should be considered a risk (and not working with multiple users), and it’s generally very slow.
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.
> Hm. Using Nix looks interesting (I’m a fellow Mac user).
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).
The main binary cache for NixOS is built using Hydra, an open-source CI system for Nix which is much older than Cachix.
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!"
But Homebrew is first in the metric that really matters, availability of the packages that people want to install. Like I just don’t care about the minutia when all I ever have to do is add some lines to my Brewfile every now and again and run brew bundle to completely set up my system.
What you're saying is hype is all that matters, as hype is the only reason new packages are added to Homebrew, and only because Homebrew got to the developer first, which is to say, by accident. But not all package managers were created equal. Hype is just hype, a tribalistic enthusiasm for the team you arbitrarily happen to support. But if the foundation is weak, and it really is, the underlying egotistical ideology of ignoring the standards of the targeted system, then everything that is built upon it is in jeopardy of failing, and to mitigate this Homebrew requires unrelated projects to keep it functional. It's a bloody mess and makes a bloody mess. So beating the alternatives to the developers door, the alternatives that aren't even bothering to do this, is what you say is the only metric that matters. You're saying politics is all that matters, and effectively claiming substance (the quality of the code and adhering to standards) is irrelevant. Ok. \o/
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.
> After using Homebrew for only a short time, you'll have a mess on your file system. Good luck cleaning it up.
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.
Sure, but that’s a known flaw, and it’s also not a use case I have. I already said I’m not a fan of it’s design, but feel compelled to use it because of its dominance. Brew is solidly a “worse is better” proposition. I do not care nearly as much about how my package manager works as long as it has the packages I need when I need them. This is the priority for user experience.
I feel you, sudo port install <package> is way too complicated. btw, anything in brew can be anywhere else, like macports or nix, all it takes is a maintainer to sponsor it. But I have to respect your brand loyalty, even in spite of fatal flaws and less than a quarter of the packages available elsewhere. It is then recommended that you never install anything else into /usr/local. But some tools will install there by default, such as BBEdit command line tools that will default to /usr/local/bin, which actually abides by the UNIX filesystem standards by doing so.
> But I have to respect your brand loyalty, even in spite of fatal flaws and less than a quarter of the packages available elsewhere.
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:
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?
> 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.
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.
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.
> 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).
> 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.
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.
NetBSD's package manager is pkgsrc, which (at least on foreign systems) uses /usr/pkg for the source tree and /opt/pkg for installs.
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 wouldn't call it completely painless when I tried it a few years ago. Compile times can be very long for some packages (try installing pandoc and all its required dependencies) and there were definitely a few package that just didn't work, though I don't remember which ones now.
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!
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.
brew is horribly slow, auto updates on any invocation I make and isn't nice to use when managing different versions of a package. It doesn't install Android studio for me correctly. Its also not reproducible. And it depends on github. And all build recipes are just Ruby, so its slow to parse and easy to pwn.
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
> I sure wish Homebrew would cease being cited as a standard or defacto package manager for macOS.
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.
Homebrew is rough if you use it for everything but haven't run it for a while, then need any (one) thing updated or installed quickly. It's probably best still since most popular means most problems discovered and fixed quickly, and will remain so as long as having updates forced only loses the stragglers.
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.
> 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.
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.
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
As a recent Mac adopter after spending 10 years as a Linux user, Homebrew is exactly what I need it to be.
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.
> 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 with [my] 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.)
I think we'd all have a better time if Apple would let us run current versions of xnu with only Darwin without having to piece everything together to end up with a system than might work but just won't because xnu is proprietary. I think there are valid cases where Darwin can be a more attractive choice than Linux, but there's just no interest because xnu is unattainable, and the alternative is using a Hackintosh kernel with degrees of stability rather than it being straight up rock solid stability. I don't mind the requirement of Macintosh hardware, but that isn't good enough for Apple, you either take the whole system or nothing (or live vicariously dependent on a few intrepid kernel hackers).
> cited as a standard or defacto package manager for macOS
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
AppStore is the default package manager in macOS since 2008, released fully mature a full year before Homebrew was conceived. Homebrew is still not mature, and only works for one user on a multiuser system. Every other available package manager doesn't have this flaw. Homebrew is worse than forgoing package management and just using git. Homebrew is pure hype, and without the hype, it has nothing.
A package manager or package-management system is a collection of software tools that automates the process of installing, upgrading, configuring, and removing computer programs for a computer in a consistent manner. [0]
If it installs, upgrades, configures and removes programs, App Store is indeed one of these. Apple invented package managers in 2008 (LOL).
ehh.. I worked in platform/systems team for companies that were step below FANG and we would routinely use brew (with ansible and shell scripts) to setup engineering and office laptops. I can't recall other package managers that have the same following or support as brew.
MacPorts has active support. Join macports-users@lists.macports.org and report your issue, you get instruction from members of the listserv within minutes. Report a bug, and it is routed and assigned within the hour, usually solved within days. Sometimes bugs take a little longer to solve, but generally they always are. In regards to Homebrew support, what are you referring to? I can't find any active Homebrew support, just the FAQ which details what isn't supported and gives lame reasons why.
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.
When Homebrew was written, neither it nor MacPorts had widespread binary caching by default like they do today.
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.
[1] https://invidious.osi.kr/watch?v=y8OnoxKotPQ