Bingo – The missing package manager for Go binaries (Homebrew for “go install”)

That's honestly not a bad way to do it.

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

> languages without first-class package managers (like Ada

Ada has a package manager, which also handles toolchain install across multiple platforms: https://alire.ada.dev/

You lose most binary caching if you do that, which is the major advantage of Homebrew over MacPorts cited by the relevant poster.

I don't know on MacOS, but on NixOS nix fetches pre-built binaries from Cachix. It only needs to build derivations if you customize them.

> When you do that, do you also need to compile the applications during installation…? (E.g. stuff written in Rust/C/C++)

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

> 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).

This is what I do as well.

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.

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/

No, it’s not completely painless. You need to recompile a lot of packages and are spammed with warnings.

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.

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.

No, even using packages that just download binaries, its still slow as wading through petrified excrement.

> just that it’s possible to use without running into them, which is why I haven’t felt compelled to switch.

Try using from another user account

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).

[0] https://en.wikipedia.org/wiki/Package_manager

> 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.

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

https://repology.org/repositories/statistics/nonunique