Comment by devkit1

I do something similar. I bootstrap all my new installs with brew cask https://github.com/fastily/autobots/tree/master/macOS/setup

> softwareC # available in nixpkgs, but because nixpkgs maintainers are hardline purists it takes 15 minutes to compile

What actually happened is that non free software may not be legal to distribute from nixpkgs caches, so you're on your own with building those. That's not really a purist approach.

> nixpkgs maintainers are hardline purists

On the contrary, Nixpkgs is generally made by the most pragmatic people and takes a flexible approach to a lot of issues. For instance, very few package managers have packages for proprietary software like 1Password in their official repositories. Nixpkgs also doesn't insist on building everything from source when it's hard to do so. As a result, Nixpkgs contains many packages for NPM or Maven projects. Other package managers insist on packaging all its dependencies from source, which is why they're struggling to package software written in modern programming languages.

As for 1Password, it works fine on NixOS. When installing proprietary GUI apps like 1Password on macOS, I just use Casks. I suspect many people do the same, which might lead to the 1Password package not working as well on macOS because fewer people bother with it.

Brew-Nix might be able to cover some of those gaps, but probably not all of them. But almost certainly SoftwareC, at least!

https://github.com/BatteredBunny/brew-nix

> softwareC # available in nixpkgs, but because nixpkgs maintainers are hardline purists it takes 15 minutes to compile from source and ain't nobody got time for that

Which package is that? Is it proprietary but source available? Any free software which is built from source is built by hydra and available from the binary cache to downstream users.

Can you just "pronounce" it (even in your head) S-pack, as in "source package"?

That's fair, but I was specifically responding to the part of OP's comment that said that compiling and installing comments was what they expected "most people" used homebrew for. I would expect the vast majority of homebrew users to be installing the built-in formulas for pretty much everything.

I do recognize that there's a bit of ambiguity around when the "compiling" happens, since even the binaries being distributed are still being compiled from homebrew's formulas. The main point I was trying to make was that there was a transition from the "compile everything on the user's local machine when installing" model that homebrew started with to "use the pre-built binaries that homebrew has compiled in advance for installing when possible if the user hasn't specifically expressed they want to compile it themselves". To be clear, I think this is a good thing, and it's a pretty huge quality of life improvement, but I've noticed a few times over the years that this change seems to have not been as widely noticed as I'd expect given how visible it seemed to me even as someone who only uses MacOS on my work machines and not my personal ones. I still sometimes get frustrated with homebrew feeling a bit slow compared to my preferred Linux package manager, but overall it's become far faster and less error-prone over the past decade, and I think it's worth calling out efforts they've taken (like pre-compiling and distributing binaries) that have made a noticeable impact.

In some ways, I think I think understanding the previous efforts they've taken might even help explain why they've chosen not to put in the effort to work around the quarantine issues (e.g. by using local signing like some other comments on this story have mentioned); they're a volunteer project that, unlike most standard package manages for Linux distros, are not in a position where they can easily influence the development of the OS features that might be useful for them. It makes sense to me that the most valuable use of their efforts would be on things that aren't swimming against the current of where MacOS is going. Getting to the point where they could have seamless binary installations at all can't have been an easy task, and the infrastructure needed for it takes additional effort beyond the local compilation model (which still exists). If cutting down on the scope in one dimension makes it easier for them to continue providing the overall feature set they have, this seems like a worthwhile tradeoff to me.

Also if you have an older version of macOS. It will try to take the compiled route for packages but also prints a stern warning that your setup is unsupported.

Sigh, I'm so over homebrew's hipster rubyist brewery analogy

You can make your own tap (which is just a GitHub repo) and manually clear the quarantine flag in a postflight step. E.g., see https://github.com/alacritty/alacritty/issues/8749

Users will need to `brew install myorg/mytap/appname` instead of just `brew install appname`, but I think that's the only real option at this point.

You can still use Librewolf, if you manually remove the quarantine attribute after every update and reboot. It’s very annoying, but at least it’s possible for now

xattr -dr com.apple.quarantine /Applications/LibreWolf.app

If Homebrew auto-signed third-party code, that puts them on the line for the security of that code. The whole point of MacOS developer certificates is to increase the trustworthiness of the software you run on your machine. The trust comes from the formal relationship between Apple and the software developer, which includes a traceable financial transaction. If signed software proves to be malicious, attribution is trivial.

If the homebrew team signed everything, they would immediately become a target for bad actors. The bad actors would flood homebrew with malicious binaries, which homebrew would auto-sign, users would download & run, and the bad actors would laugh all the way to the bank.