5 ms·

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: > Ma

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 Sounds horrifying

amake 5y ago
> > MacPorts distributes source code that is compiled on install, so Macports is generally much slower to install packages False. Binaries, built from source, are used by default.
siraben 5y ago
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/
pxc 5y ago
> Sounds horrifying Let's break this down. > 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).
- rapsey 5y ago
  There is nothing keeping you from installing homebrew in your home folder. It is completely painless. No root required.
  - ck45 5y ago
    No, it’s not completely painless. You need to recompile a lot of packages and are spammed with warnings.
    - rapsey 5y ago
      I have had zero warning spam and no issues and I use it a lot.
      - pxc 5y ago
        If you run `brew doctor` on a brew installation with a custom prefix, you get several spurious warnings depending on what all you have installed. It's not spam, but it is annoying if you're trying to use `brew doctor` in an automated process.
saagarjha 5y ago
MacPorts has binary builds for a lot of packages these days–pretty much everything that they can distribute without licensing issues.
sdedovic 5y ago
> I've never seen a better alternative for macOS 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!
- _y5hn 5y ago
  I can't speak for macOS, but on Linux using Nix as package manager is relatively painless once you follow a recipe such as this one: https://www.tecmint.com/nix-package-manager-for-linux/ https://www.tecmint.com/nix-package-manager-for-linux/ 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.
eptcyka 5y ago
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.
- IshKebab 5y ago
  I agree, Homebrew is really slow, but as slow as compiling everything from source.
  - eptcyka 5y ago
    No, even using packages that just download binaries, its still slow as wading through petrified excrement.
- dmitriid 5y ago
  >auto updates on any invocation 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
AnonC 5y ago
The MacPorts approach is not horrifying or worse. This blog post [1] from April 2019 makes a good case for MacPorts and against Homebrew. [1]: https://saagarjha.com/blog/2019/04/26/thoughts-on-macos-package-managers/ https://saagarjha.com/blog/2019/04/26/thoughts-on-macos-pack...
Maursault 5y ago
> Homebrew has been around for a long time. 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.
- jolux 5y ago
  > 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.
  - Maursault 5y ago
    > 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
    - jolux 5y ago

amake 5y ago

> > MacPorts distributes source code that is compiled on install, so Macports is generally much slower to install packages False. Binaries, built from source, are used by default.

siraben 5y ago

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/

pxc 5y ago

> Sounds horrifying Let's break this down. > 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).

rapsey 5y ago
There is nothing keeping you from installing homebrew in your home folder. It is completely painless. No root required.
- ck45 5y ago
  No, it’s not completely painless. You need to recompile a lot of packages and are spammed with warnings.
  - rapsey 5y ago
    I have had zero warning spam and no issues and I use it a lot.
    - pxc 5y ago
      If you run `brew doctor` on a brew installation with a custom prefix, you get several spurious warnings depending on what all you have installed. It's not spam, but it is annoying if you're trying to use `brew doctor` in an automated process.

saagarjha 5y ago

MacPorts has binary builds for a lot of packages these days–pretty much everything that they can distribute without licensing issues.

sdedovic 5y ago

> I've never seen a better alternative for macOS 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!

_y5hn 5y ago
I can't speak for macOS, but on Linux using Nix as package manager is relatively painless once you follow a recipe such as this one: https://www.tecmint.com/nix-package-manager-for-linux/ https://www.tecmint.com/nix-package-manager-for-linux/ 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.

eptcyka 5y ago

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.

IshKebab 5y ago
I agree, Homebrew is really slow, but as slow as compiling everything from source.
- eptcyka 5y ago
  No, even using packages that just download binaries, its still slow as wading through petrified excrement.
dmitriid 5y ago
>auto updates on any invocation 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

AnonC 5y ago

The MacPorts approach is not horrifying or worse. This blog post [1] from April 2019 makes a good case for MacPorts and against Homebrew. [1]: https://saagarjha.com/blog/2019/04/26/thoughts-on-macos-package-managers/ https://saagarjha.com/blog/2019/04/26/thoughts-on-macos-pack...

Maursault 5y ago

> Homebrew has been around for a long time. 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.

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