Thanks for the hard work, but the Tahoe limitation for the GUI app is absolutely ridiculous.
Homebrew 7.0.0
181–190 of 270 posts
Re: Homebrew 7.0.0
#182[flagged]
How is that any different from PyPI, npm, cargo, etc?
Brew however is a system level package manager so it is expected to install your top level tools with substantial privilege, so for using it on a production capable system you would want maintainer signed commits, maintainer signed reviews, and 2+ maintainer signed reproducible builds, all with well known long lived keys controlled by smartcards of each maintainer on high trust systems.
I am not just talking out of my ass here. We do all of the above in stagex because it is the bare minimum.
Re: Homebrew 7.0.0
#183Time to `brew update && brew upgrade` later today. Always a little nervous, but Homebrew usually makes it painless.
I have this bound to an alias: bu Run it every couple of days, easy peasy.
Re: Homebrew 7.0.0
#184Re: Homebrew 7.0.0
#185Farewell, Homebrew. It's been a good run. - 2019 Intel iMac user.
We've all gone through it :-( Happy users of the (really good) software until our hardware gets "too old" and the inevitable rug pull.
Entitlement can be wild, volunteers are volunteers. Consumers of volunteer output are free to support their use cases themselves on their own time. Find an ARM Mac used (like an M1) and upgrade.
Re: Homebrew 7.0.0
#186I prefer to use Mise for everything nowadays. homebrew bootstrap specifically. A lot easier to manage all of my packages in one single file, homebrew, Node packages, etc. https://mise.jdx.dev/bootstrap/packages/brew.html
mise has been an absolute delight.
Re: Homebrew 7.0.0
#187As a MacPorts users (generally light-weight, just a few things here and there): Has anyone gone from MP to HB, or vice versa? Why did you switch from one to the other (and perhaps back again)? What did you find as the pros/cons of each?
Re: Homebrew 7.0.0
#188I found that Mise handles all my needs for development and it is scoped so it doesn't try to update Python and break all my virtual env when I install something new /shrug
I split my usage. Homebrew for OS things mise for the various tooling. The only problem some things still have a dependency on requiring python and others on the system. The problem being that they’re there, mise works just fine.
This is all you have to add to the config file:
[bootstrap.packages]
"brew:git" = "latest"
"brew-cask:ghostty" = "latest"
Re: Homebrew 7.0.0
#189As a MacPorts users (generally light-weight, just a few things here and there): Has anyone gone from MP to HB, or vice versa? Why did you switch from one to the other (and perhaps back again)? What did you find as the pros/cons of each?
Homebrew's best differentiated strength imo is the whole Cask subsystem, which basically automates GUI app installs via "first-party" artifacts like .dmg and .pkg files. That's what I still sometimes use it for even though I have other package managers available, including MacPorts, that I prefer for most other things.
The ordering goes something like the following: Nix > pkgsrc > MacPorts > Homebrew > mas (CLI frontend for the App Store).
Each kinda has its niche. Nix is just generally preferable for me, and it covers all of my needs 99% of the time. It also happens to be pretty fast in terms of actual installation even if evaluating the Nix code can be slow for complex projects.
For proper development toolchains, it's all Nix all the time. Those are per-project rather than global, and what can't be managed by Nix isn't managed at all. Nix is this an overriding constraint there, which has never really been a problem for me.
Pkgsrc is good for development tools and terminal apps, but Nix is generally even better for those, so for me it's just an escape hatch in case something is broken or missing in Nixpkgs and I'm too lazy to fix it, or I genuinely want some library installed with its headers findable globally (rare, because that's mostly bad practice imo). Also good if I want a backup copy of an exotic shell or something in case I want to rm -rf /nix and not be forced back into Bash or zsh, which is nice when I'm working on my macOS bootstrap scripts. On macOS, everything you install via Pkgsrc will be a binary install, so it's relatively fast and its performance is relatively predictable.
MacPorts is broadly useful so it's useful for the same things as Pkgsrc, but it's also better at providing GUI Mac apps, built from source. For a while I got Emacs here when Emacs in Nixpkgs had a problem building with native compilation support, for example. Also good for my macOS bootstrap scripts since they're written in literate style in Org mode; it can be nice to have a working Emacs to dump them to disk with even without Nix if I'm iterating on them. MacPorts often ends up building stuff from source on my system, which can be slow, but I don't care because I have very little installed via MacPorts.
Homebrew historically didn't feel "safe" for me for development dependencies for various reasons. Before sandboxing support, running and installing and managing things as your own user felt especially unsafe from a security perspective. Now it's a lot better, but it still feels wrong to have global-ish prefixes owned by a particular user. The aggressive in-place upgrades also feel quite brittle for development dependencies, but to some extent that's true of anything that's not project-local. I also don't like that installing GUI apps with Homebrew can end up putting binaries related to their dependencies and not needed at runtime into my PATH— that feels way messier than what I get with Nix. It can also historically be very slow for what it does, but if you're using it in the recommended way, you don't often have to build from source so you can still expect a faster experience than with MacPorts even though both nominally support binary packages.
All that said, Homebrew shines when it comes to extremely broad support for arbitrary Mac apps, often including proprietary ones, and support for the arbitrary range of installation procedures that macOS app developers expect you to use. It's also very good in terms of freshness for macOS packages. Nix is competitive in that respect, but none of the others remotely are. The stuff I don't like about where Homebrew puts things and the filesystem permissions are also fixable if you use a custom prefix. That's officially unsupported and means you can't use "bottles" (i.e., you'll need to build packages that aren't "casks" from source), but it works fine and has been totally stable for many years. If you understand some basic Unix norms and how to compile software from source, you should feel comfortable doing it.
I also like to keep Homebrew's bin/ paths off my PATH, and selectively symlink or wrap binaries installed via Homebrew back to ~/.local/bin by hand. That way I can install whatever I want via Homebrew without worrying about it getting unexpectedly involved in my development processes or command-line environment.
Because Homebrew has historically been so slow for me, I've tried to install as little with it as possible, which means installing even some Mac GUI apps via Nix. That's kind of a pain because if you want Spotlight to pick them up, you need little trampoline wrapper apps because it won't register symlinks into the Nix store. And when Nixpkgs' selection is lacking, you can extend it with brew-nix, which uses Homebrew's JSON API to automatically generate Nix packages. They work, but some apps just can't do everything they're designed to from the Nix store due to macOS limitations/security policies, so you have to kind of figure out which you can install via Nix yourself. It's extra machinery, and so if Homebrew is faster enough now I may look forward to dropping it and just using Homebrew as my first choice for all GUI apps.
The App Store sucks, needless to say, not least of all because it requires an active login to a large tech company. I only use it for VPN apps or security software where Apple forces me to.
I don't recommend my setup to people for whom package managers aren't a first-class interest, but it is perfectly stable and it's unlikely to get you into trouble.
I think most people would be served well by combininations of two package managers, of one of two forms: Nix + an escape hatch or Homebrew + a development toolchain manager.
For people who like macOS' app installation procedures: Nix + pkgsrc
For people who like Nix but want a disciplined escape hatch: Nix + MacPorts
For people who like Nix and want absolute coverage: Nix + Homebrew
For people who don't really care about how their package manager works but are developers: Homebrew + mise or Homebrew + Nix
For non-developers who just want an automated/centralized way to install software aside from the App Store: Homebrew (and probably especially the GUI)
I think the main thing for me is just that no one should have free-floating, ambient development dependencies. You shouldn't have some software project that depends on what version of Python is on your PATH or what packages from PyPI are globally installed via pip or whatever. You shouldn't be manually building unoconv or pandoc or something against some LibreOffice headers that live in /usr/local or /opt/local or anywhere like that. Ideally, shouldn't be doing `make install` anywhere— if you need to compile something for your own use, compile it by writing a package (or having an LLM write it, you lazy bum). If you observe that kind of basic package management hygiene, "switching" is largely trivial and doesn't involve any manual cleanup or fixing.
And if you spend a few minutes thinking about a preference order that you like and configure your PATH accordingly, all of these package managers can coexist so that you can "switch" gradually, at your leisure.