I tried hosting a homebrew tap, after hosting apt and yum repositories.

That was when I realized Homebrew is much, much harder.

Your server needs to implement the git protocol. You can't just stick it on some server with a CDN in front of it, you need to run and fortify a git server.

Strange choices IMHO.

I assume this trust issue is related to the not-infrequent MacOS notifications asking for permission to run Ruby in the background or when the machine starts. It says nothing about Homebrew though.

Awesome! Thank you for the update.

I noticed that homebrew updated _all_ my casks when running 'brew upgrade' (even those with "auto_updates: true" in their Cask JSON API).

Is this intended, new default behavior? This did not use to happen...

Is there a way to `brew trust` inside my Brewfile? That'd be nice for the handful of formulas I install from github repos via `brew bundle --global`.

Thanks for producing such an amazing piece of software. Most of my Mac installations are based on Homebrew, but I have to rely on version management tools like Pyenv or nvm for Python and Node. Wish there was some standard 'Homebrew' way to install multiple versions of node, php and Python

Personally I stopped using Homebrew after I got screwed too many times on mandatory upgrades that I couldn't pin. I use a combination of Mise and MacPorts now so I don't get any more surprise breakage and forced obsolescence. Plus Mise allows me to upgrade to any new version, whereas with Homebrew you have to wait for whenever the tap feels like upgrading (llama.cpp tap skips every 10 releases)

Interesting that the `brew-rs` experiment has concluded and didn't find much of a performance increase. I suppose that is expected though with a lot of the bottleneck being network IO?

Is the eventual goal to move most formula/cask behavior into declarative install steps and treat Ruby as an escape hatch?

Does Homebrew have good support for exact (and older) versions of packages now?

Thanks for the hardwork.