6 ms·

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 v

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.

rapsey 5y ago
Homebrew does not need to be in /usr/local everything will work fine running from your home folder.
- pxc 5y ago
  You lose most binary caching if you do that, which is the major advantage of Homebrew over MacPorts cited by the relevant poster.
cpach 5y ago
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?
- angio 5y ago
  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.
  - pxc 5y ago
    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.
- siraben 5y ago
  > 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 https://hydra.nixos.org/jobset/nixpkgs/nixpkgs-21.11-darwin
- rgoulter 5y ago
  > 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 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).
bloopernova 5y ago
For anything versioned, I use asdf: https://github.com/asdf-vm/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!"
- amrox 5y ago
  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.
Spivak 5y ago
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.
- Maursault 5y ago
  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/

rapsey 5y ago

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

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

cpach 5y ago

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?

angio 5y ago
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.
- pxc 5y ago
  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.
siraben 5y ago
> 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 https://hydra.nixos.org/jobset/nixpkgs/nixpkgs-21.11-darwin
rgoulter 5y ago
> 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 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).

bloopernova 5y ago

For anything versioned, I use asdf: https://github.com/asdf-vm/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!"

amrox 5y ago
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.

Spivak 5y ago

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.

Maursault 5y ago
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/