Show HN: Homebrew 6.0.0

17 in September. Thanks for all your great work at the time! Hope you’re well <3

Homebrew is so good that I use it on Linux whenever possible.

Most Linux package managers cannot separate user-installed packages from system packages. This makes cleaning up your workstation nearly impossible and a pain in the ass, since you can't tell what should be removed, or more importantly, what can be removed.

Also, most native package managers update much slower than Homebrew, meaning you often only get outdated packages.

  comm -23 <(apt-mark showmanual | sort -u) <(gzip -dc /var/log/installer/initial-status.gz | sed -n 's/^Package: //p' | sort -u)

[dead]

Mise does seem to be in a class of its own. As mentioned elsewhere, it does rely on other registries such as aqua and obviously asdf. For people who want to use Mise for brew packages, there's https://github.com/kennyg/mise-zerobrew.

Glad you're having a good experience, but I personally switched from Mise back to Brew. I don't know if it was just my skill issue, but there were too many packages which found Mise to be problematic.

As a PHP developer, I found mise's support to be pretty sub-par compared to Shivam Mathur's packaging work for homebrew. Most of my projects are using Docker anyway, the local PHP is for stuff like static analysis that doesn't need it. And I've got a couple using Nix, which laughs at everything else (but damn, the overall UX is still even more hostile than git).

mise kind of supports dependencies, just not in the way people expect coming from any other package manager. The dependencies in mise are not automatic and all of them need to be manually defined. They're to get around ordering issues since mise installs in parallel, e.g.: if you use "pipx:black" you need to wait for python to finish installing. (This is the "depends" option on tools")

This is intentional as mise is not intended to be a full bootstrapping solution in the way homebrew/nix is, mise is designed to be an overlay on top of existing systems. So if you want to manage python with brew and black with mise it basically just works without extra configuration. I think this design decision has paid off in spades. It sounds like a drawback but at the end of the day it's probably the #1 reason users find mise easy to use.

I like mise a lot, but only use it for project specific tool management, JDK versions, etc.

I tried to use it for system wide things, but found it didn't work as well for me with things that I wanted to just be tools where I didn't care what specific version it was as long as it was more or less current, Helix, NeoVim, RipGrep, etc.

I did the same but with Nix.

Mise actually does support a primitive dependency system, you can specify package deps in your config, so, for example, you can ensure erlangs are installed before elixirs (bad example, elixir is already internally dependent on erlangs, but you get the idea)

https://mise.jdx.dev/dev-tools/#tool-dependencies

Mise’s refusal to make global packages globally available is off-putting. I keep using it for specific Node versions and the integration with fnox.

The big drawback: having Claude complain every couple of hours that the new worktree is untrusted; or having to prefix a bunch of commands with `mise exec …` is annoying as well. A global alias for all shells would be nice.

Hmm, `mise use -g docker-cli` works for me. `docker compose` is a bit trickier – it gets installed as `docker-cli-plugin-docker-compose`, but docker-cli doesn’t seem to pick it up. I’ve added a symlink as `docker-compose` for the time being.

Also using brew for casks, and I think there’s a couple tools I couldn’t install with mise (e.g. pngpaste and zbar for scanning QR codes from screenshots).

  #!/usr/bin/osascript -l JavaScript
  
  ObjC.import("AppKit");
  $.NSFileHandle.fileHandleWithStandardOutput.writeData(
    $.NSPasteboard.generalPasteboard.dataForType("public.png"),
  );

  "github:docker/compose" = { version = "latest", rename_exe = "docker-compose" }

  DOCKER_CONFIG="${DOCKER_CONFIG:-$HOME/.docker}"
  mkdir -p "${DOCKER_CONFIG}/cli-plugins"
  ln -s "$(mise which docker-compose)" "${DOCKER_CONFIG}/cli-plugins/docker-compose"

Mise does support docker cli - that’s how I use it with Colima - what’s not working for you?

I really like mise but I don’t think it’s an adequate homebrew replacement. I use it more for project management dependencies and tasks.

Don't forget that mise depends on package registries, to install itself as well as its tools.

Do you have an example? Sounds interesting.

    mise use -g somepackage --pin

    mise up -il

[dead]

[dead]

That's kind of weird that you're using this announcement to steer people to another project.

Or am I missing something..?

The concept of a "userspace package manager" is something I would expect Linux to have figured out twenty years ago. It's ridiculous that the usual situation for non-root users is "you can't install XY but feel free to build from source". Homebrew, Mise and Nix are filling that hole now. (Flatpak is more oriented towards GUI apps, and Snap... exists.)

  echo "deb [signed-by=/etc/apt/keyrings/packages.mozilla.org.asc] https://packages.mozilla.org/apt mozilla main" | sudo tee -a /etc/apt/sources.list.d/mozilla.list > /dev/null

  # 1. Install our official public software signing key:
  wget -O- https://updates.signal.org/desktop/apt/keys.asc | gpg --dearmor > signal-desktop-keyring.gpg; cat signal-desktop-keyring.gpg | sudo tee /usr/share/keyrings/signal-desktop-keyring.gpg > /dev/null
  
  # 2. Add our repository to your list of repositories:
  wget -O signal-desktop.sources https://updates.signal.org/static/desktop/apt/signal-desktop.sources; cat signal-desktop.sources | sudo tee /etc/apt/sources.list.d/signal-desktop.sources > /dev/null
  
  # 3. Update your package database and install Signal:
  sudo apt update && sudo apt install signal-desktop

I've been using it under linux and have been very (surprisingly?) happy with how it runs especially when compared with current package managers.

I'm using nix on Bazzite, with home-manager

https://docs.brew.sh/Supply-Chain-Security details how we’re handling cooldowns and why we have a very different risk profile to e.g. NPM.

Also, where we package things from NPM/PyPi/RubyGems that have been subject to these attacks: we already apply cooldowns for you both when packaging and when creating PRs to update to new versions.

    Bundler
    RubyGems livecheck
    npm and pip defaults
    PyPI resource resolution
    npm and PyPI in bump

+1

For those who don't know what broxit is talking about, they're referring to something like --minimum-release-age/minimumReleaseAge in many pieces of software and package managers to reduce vulnerability to supply chain attacks. Often times, such attacks are detected within a few days of compromise.

Here's Bun's, as an example: https://bun.com/docs/pm/cli/install#minimum-release-age

Most handle this by having release channels. You would `brew set-channel stable/edge`.

It annoyed me this week because I only had a few minutes to try elixir 1.20 after the announcement, and brew lagged behind. You can install erl and elixir by other means (I prefer to run my own toolchains) but it wasn’t worth doing in that moment.

Brew has or used to have a source option for some recipes and that basicallllly solves it too, if you squint.

It's in this release, see this section:

> Cooldowns, livecheck and bumping

It's all rolling release, but Homebrew maintainers have to bump the version, not the software author (unless they put in a PR to Homebrew core or publish their own Tap). What does Arch do here?

100% need this.

I'm amazed they're not sponsored by Apple themselves, or at the very least major mac-forward Dev houses.

I use nix-darwin and also manage my homebrew packages with it. Maybe you can take a look at that.

May I ask for what do you use it at work? I have a few places I think nix might suit but I can’t really put my finger on it.

I was interested in Nix because it could automate setup and configuration of macOS features. But all it does is usually run defaults or some intermediatary. In the end I stuck with brew and wrote an idempotent setupmac() function in my bash_profile (I use bash 5) with the aid of chatgpt since it knows all the cool defaults commands, and it’s pretty much solved setting up a new account or mac (alongside a Brewfile I maintain in my dotfiles). I don’t need any of those highfalutin tools.

Very glad to hear this, thanks for posting.

I've moved over to MacPorts due to Homebrew's aggressive support phase-out schedule[1]. My daily driver iMac is now in the Tier-3 "go away" bucket. Absolutely loved Homebrew for the short period of time I could use it, but I'm not going to get on the hardware update treadmill just to keep using it.

1: https://docs.brew.sh/Support-Tiers

I was going to ask about others having this experience. I've been using MacPorts for a couple years to install developer tooling because it's far more consistent and doesn't surprise me with new major versions of Python at random. I only use Homebrew for application installation (i.e. Firefox, Slack, Spotify, etc.) that are not available in MacPorts.

Of course, I've also made a concerted effort over the years to migrate everything to uv for Python, pnpm for nodejs, etc. so maybe it's not an issue for me anymore?

Nix is also worth checking out, even if the Darwin packaging is a bit flaky. I really appreciate having cross-platform devshells when I have to alternate between Mac and Linux on a regular basis.

Glad you've found a workflow that works for you, genuinely.

For others still using Homebrew: a lot of work has gone into upgrading only when we absolutely have to and showing these upgrades to the user before we do them, including in this release.

I switched to MacPorts because of permission issues with brew, used it for years, then switched back after MacPorts inexplicably started wanting to install like 9000 packages just to install something small-ish like wget. Which is probably just as likely to happen with any other package manager but whatever.

I'm in the "switched most to Mise" stage, might look into MacPorts for the remaining stuff, thanks for the tip!

> We'll lose support from you guys a year before Apple!

If only Apple put a fraction of its resources towards maintaining something like homebrew (or paying the people who do), maybe the situation would be different.

If anything, the overwhelming majority of Apple enthusiasts have gone all-in on Apple Silicon. I sincerely doubt those using old Macs as servers are anything but a rounding error.

> We'll lose support from you guys a year before Apple!

Homebrew will still work (increasingly poorly) on macOS Intel for a year after that, it just won’t be “supported” or tested in CI environments (where currently macOS Intel usually slows down the release of lots of software for all other platforms).

That a volunteer run project with no employees is unable to come anywhere near the support levels of the world’s second biggest, trillion dollar company should not be surprise.

We’re also limited that GitHub (part of Microsoft, 4th biggest, also trillion dollar company) will have killed all macOS Intel CI by autumn/fall 2027 too.

We are announcing this well in advance to give people migration paths to MacPorts or other hardware.

There’s nothing stopping you for doing the work to setup “Intelbrew” and support it for the community. When I started work on Homebrew it had no funding or CI or binary packages/bottles at all. I did much of that work myself. It was hard but you could do the same.

Completely reasonable to say “I don’t have time!” but: then you need to accept the decisions of those that do, sorry.

At this point that would be a 2018 Mac mini, which can only run Sequoia (which will be out-of-support at the same time as Homebrew drops Intel support).

If you want Intel support, MacPorts still runs back to Leopard.

Yeah they also removed support for --no-quarantine flag :/ I only use it for a few casks nowadays and try to avoid Homebrew as much as possible. For CLI stuff I use Nix, Home-Manager and Nix-Darwin.

AFAIK, github action runner for intel will be deprecated at similar period, maybe that is major reason.

A saving grace is they're perfect for linux distros.

Does brew gather statistics that could show what portion of users is on Intel vs Apple Silicon?

I would say I’ve embraced AI most heavily and I wrote this document so: yes.

I review AI written code on Homebrew the same way I review code from a no avatar GitHub user with no previous contributions.

The experimental and abandoned brew-rs frontend was more “vibe coded” using my knowledge of how to benchmark and test homebrew accurately and with a shitload of manual testing. Maybe that’s why the performance wasn’t as good as expected, who knows.

Most nix users still use brew for casks on mac. Using brew bundle as your interface to it makes things almost seamless, so its not too icky overall.

eg I manage my Brewfile declaratively with home-manager, and then run this on file change

        HOMEBREW_NO_UPDATE_REPORT_NEW=1 HOMEBREW_NO_AUTO_UPDATE=1 brew bundle --file="$HOME/Brewfile" --cleanup --no-upgrade

> since you can't tell what should be removed, or more importantly, what can be removed

Isn't that what dependency detection does? Whenever I'm not sure if something can be removed, I just try to remove it, and if it would break something else, the package manager tells me. I can broaden my scope and see if that's also an unnecessary dependency for something and follow the chain, with it eventually ending up with a set of packages where I actually get the prompt to proceed or not (meaning nothing in it is a required dependency for anything remaining), or I see a package I definitely want to keep around and stop. If I'm interested in what's part of the base system, I just check the metapackage for the base system.

This doesn't sound like something that's a problem with package managers in general compared to maybe some distros just using them poorly.

Curious about this. Usually I try to get an Apt source (I use Ubuntu). Why would I want to use brew on Linux? I stopped using Macs and brew around 2018 when Apple started closing down it's macOS for a few years and got sick of it. Thanks!

Not sure if everyone is going to get your joke, but it's a very good one.

OSS Resistance is about not asking for time to do something yourself while removal of unsigned casks is about what they host in the official Homebrew/cask repo. You're free to make & use your own tap to use with Homebrew without asking, so there's not really anything to square between the two stances - any conflict all comes purely from your 3rd stance about signing in general.

I just threw them a small donation for supporting this software for so long, even if it's only 98% how I'd want the project to be run all these years myself.

I square them because both of them allow me to do lots of open source work and enjoy it.

Your signing point is not accurate. It doesn’t apply to all packages, only casks in the official tap. With casks the trust model, particularly on things that auto-update and don’t expose versions or checksums on download URLs, heavily relies on Apple’s security guardrails. We pushed against them for a while but Apple’s direction of travel made it clear that it was a waste of our energy and that we were at risk of compromising our users through doing so.

You can still automatically remove quarantine in third-party taps as desired, we’re just making it less easy to do so because we consider it a security feature that should require a deliberate bypass.

I don’t think anyone is obliged to donate to Homebrew but this sort of framing, assuming you use Homebrew, isn’t great. If you find what we do morally distasteful: go use something else. MacPorts, Mise and Nix are all good. This will be better for everyone than using us begrudgingly.

Yeah, I remember this story too. Crazy, it most definitely feels like the organization missed an opportunity.

We’ve complained about this to Google many times to no avail. It’s very frustrating. They are literally paid money to let people install malware on your machine. Please direct all annoyance and resentment to them (we share it).

I've heard of that but never experienced it on my Google. Weird. I just retried that now and it's giving the correct link. Maybe that's why it's not being fixed.

[dead]

Try `brew version-install` (which uses `brew extract` and `brew tap-new` under the hood)

Yes, exactly. The goal is you can install all official packages without needing custom postinstall/preflight/postflight blocks.

You need to set HOMEBREW_NO_UPGRADE_AUTO_UPDATES_CASKS to 1, as alluded to by a hint when it (first?) occurs. This means if you have hints off (via HOMEBREW_NO_ENV_HINTS) then I suspect you can start getting this behavior without warning which is a bummer.

See also: https://docs.brew.sh/FAQ#why-arent-some-apps-included-during...

Yes this is intended. We skip those that seem to have already auto-updated underneath. Our code for this is not yet rock solid so please file issues for those you notice are not doing the right thing here.

This sort of overly eager upgrading has caused me a lot of problems over the years. I really wish it didn't default to updating the entire world just because you want to update one package.

Sounds like a great idea, thanks for volunteering to pitch in and help!

I don't think homebrew allows throttling bandwidth but it does let you set maximum concurrent downloads though. I believe the default is twice number of cores; you must have quite a few :) Set this to your preference:

HOMEBREW_DOWNLOAD_CONCURRENCY

You could use network link conditioner to artificially limit, or one of the apps that can enforce per app limits such as tripmode

It's still a thing: https://pkgsrc.smartos.org/install-on-macos/

I think it is focused on GitHub. It might not be suited for many people this way, but it works well. Opionated design.

You can now trust individual files inside taps. It was not clear to all users before now that some commands (before —-eval-all, a mess this replaces) would evaluate all packages Ruby code from all taps). This cleans that up and some other security degrading edge cases I won’t bore you with here.

Trust is also user specific now.

It’s not a silver bullet but it does help address some potential attacks and gives us a foundation to improve on over time.

Exactly - so far seems like a windows vista “are you sure?” Modal. Are we missing something here?

Thanks for the kind words and sponsorship <3

This is described here (https://docs.brew.sh/Tap-Trust) if you scroll down a bit.

`brew tap/recipe, trusted: true`

To brew? Sort of. I use nix-darwin for everything. However, some things don’t play nice with nix. In that case you can use nix-darwin to manage brew. Basically you give it all the packages you want, and it generates a brew file and uses it.

brew as-console-user may help here. We don’t support a multiuser setup so there may be some limitations but we try our best to address problems as they come up.

there is `brew update`

This sounds like a bug. Can you file an issue?

Thanks :)

—-no-ask, —-yes, -y or HOMEBREW_NO_ASK=1

Wdym tried?

There are many thousands of users of Linux homebrew, mostly users of atomic distros. I am one of them. I was so happy using homebrew that I've added new formula to its repo, far2l-tty

Homebrew provides access to a massive catalog of software, including many tools that are not packaged for Fedora, Debian, or Ubuntu. Homebrew relies on a high level of automation in GitHub actions, which ensures users get the latest versions of tools quickly, rather than waiting for distribution-specific repositories. The Homebrew approach also decouples the underlying system from what you choose to install in user-space.

Yes. I daily drive pop os now. Hate to use flatpak for anything. Only install core packages, google chrome and vscode using apt. Almost everything else is installed using homebrew. The idea is have a base stable system for UI and basic shell. Usually get the latest packages from brew. Earlier same base system but had distrobox with arch toolbox. Planning on using this scheme going forward, especially since while I love rolling release, they sometimes might have regressions which I don’t want to deal with right away. And these regressions can be both at system level or user packages level. Having a stable base helps significantly in daily driving linux in real world.

It's for predictability in upgrades. Homebrew allows you to separate system packages (from apt or dnf) from user packages (from homebrew) [1]. Running apt upgrade or dnf upgrade can render your system unbootable if you're unlucky (or unstable or degraded if you're less unlucky). Running brew upgrade can at worst break some of your own user's setup or tools.

Since everybody runs their own unique permutation of apt or dnf packages, adding as little as possible will keep you as close as possible to what distro maintainers test. There's even OSes like Fedora Silverblue or Bluefin or SteamOS that ship with a fully baked _image_ - where installing system level packages is strongly discouraged - which helps ensure predictability and stable upgradeability.

Homebrew packages also tend to be more recent (this depends on your distro of course) and don't require elevated permissions to install.

[1]: Other unprivileged package managers like Mise or Nix do the same of course

You can have multiple versions of tools installed. But overall, homebrew plays well with atomic distros. They are thing in itself, yet getting more popular lately. Im using them at home and on the server, and it feels calmer, because I can't fuck up whole system easily. Considering I'm using llms without sandbox often, this is pure gold.

You can run Homebrew on Linux without admin privileges. Useful e.g. for shared hosting.

We should all be ashamed of the interview culture we have created in this industry.

Comparison of which managers?

Adding package to homebrew is straightforward, except that it has a lot of (reasonable?) requirements to make it right. Basically, you make a PR with a "formula" to their main repo from your branch. Formulas are ruby programs. LLM can do it easily, and such code is accepted if correct.

Sorry, we don’t have the resources to do so. We are a team of volunteers and rely on donations to pay for our CI infrastructure.

MacPorts is a better fit for older hardware.

There's a selection of ways that may or may not work for you:

- `formula@version` packages

- `brew version-install` (which uses `brew extract` and `brew tap-new` under the hood)

- `version_file:` support in `brew bundle

- `brew pyenv-sync`

Have a look at https://mise.jdx.dev/, it's exactly what you're looking for!

I switched from brew to https://asdf-vm.com/ for this very reason.

I don't understand how devs don't use a tool that makes multiple versions of everything possible.

> Homebrew is the first thing I install on a new Mac.

Absolutely!

I'll second the recommendation for `mise`, and add: I typically use Homebrew for things I want everywhere, and if I want something everywhere then the latest version is _probably_ OK. I typically use mise en place for versions which are project-specific.

So I have a system Python (largely unused), a Homebrew python (pulled in as a dependency, I won't use it), and as many different mise/uv Pythons as I need for different projects. Similarly NodeJS and Java. I'd given up on nvm a while back, no longer use pyenv, and mise and uv work together really nicely.

Nope, still rolling. Have a look at https://mise.jdx.dev/ if you need exact versions

`brew version-install` may do what you want here.

I don't think that's a part of its goals at all.

macOS Permission Management regarding shell scripts is so bad. For example they show you a list of software thats allowed to access the full disk - but I have like 8 "sh" or "bash" in there and some random scripts with no way to open the enclosing directory in Finder making it basically impossible to see what it is and if its legit…

Homebrew first, then use it to install Sublime and Bash!

I’ve never applied for a job at Apple.

You’re maybe thinking of the creator mxcl’s viral tweet about not getting hired at Google. He did work at Apple for a while on SwiftPM.

I also am in the “applied and didn’t get hired by Google” club which let me move back to Scotland instead :)

This behaviour came about because, before we did that we ended up upgrading just what you wanted and breaking other packages by mistake.

It’s taken a long time but we’re finally at the point where we do (pretty much) only upgrade the minimal software we need to actually avoid breakage rather than the previous “better safe than sorry” conservative approach. We also now tell you by default everything we’ll upgrade before we do it (unless you say “upgrade foo” and all we are gonna do is upgrade foo).

So: we’ve maybe solved this issue and maybe not. The perfect outcomes for everyone here is pretty much impossible given the original design of Homebrew. MacPorts or Nix or Mise are likely a better fit in that case.

Are you referring how it does a `brew upgrade` when doing a `brew install`? It should tell you how to disable that whenever it happens:

> Adjust how often this is run with `$HOMEBREW_AUTO_UPDATE_SECS` or disable with

> `$HOMEBREW_NO_AUTO_UPDATE=1`. Hide these hints with `$HOMEBREW_NO_ENV_HINTS=1` (see `man brew`).

You’re thinking of mxcl, the creator, not me.

I also applied and failed a final stage job interview at Google (and various other places over the years) but never really bothered me that much.

Ironically I think I’d probably never have started working on Homebrew if it had.