Hm. Using Nix looks interesting (I’m a fellow Mac user).

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?

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

> 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

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.

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.

For anything versioned, I use asdf: https://github.com/asdf-vm/asdf

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!"

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.

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/

Homebrew does not need to be in /usr/local everything will work fine running from your home folder.

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