Nanobrew: The fastest macOS package manager compatible with brew (opens in new tab)

Context for those unaware: the commenter, mikemcquaid, is the project lead for Homebrew.

It is really coll that Homebrew provides a comprehensive enough JSON API to let people build on Homebrew in useful ways without directly running Ruby, despite everything being built in a Ruby DSL. That really does seem like a "best of both worlds" deal, and it's cool that alternative clients can take advantage of that.

I didn't know about the pending, official Rust frontend! That's very interesting.

> Homebrew is working on an official Rust frontend that will actually have full compatibility.

When you say "Rust frontend", is the vision that Homebrew's frontend would eventually transition to being a pure Rust project — no end-user install of portable-ruby and so forth?

If so (ignore everything below if not):

I can see how that would work for most "boring" formulae: formula JSON gets pre-baked at formula publish time; Rust frontend pulls it; discovers formula is installable via bottle; pulls bottle; never needs to execute any Ruby.

But what happens in the edge-cases there — formulae with no bottles, Ruby `post_install` blocks, and so forth? (And also, how is local formula development done?)

Is the ultimate aim of this effort, to build and embed a tiny little "Formula Ruby DSL" interpreter into the Rust frontend, that supports just enough of Ruby's syntax + semantics to execute the code that appears in practice in the bodies of real formulae methods/blocks? (I personally think that would be pretty tractable, but I imagine you might disagree.)

https://github.com/Homebrew/brew/tree/main/Library/Homebrew/... for reference

Heyyyy, who are you to tell us what is and isn't compatible with homebrew?

(Just kidding, thank you for creating homebrew and your continued work on it!)

I think you are doing great work with brew and I hope the Rust version is released soon

However, how is this effort different than uv vs pypi? why is this a bad thing?

Please, don't remove bottles and casks that are blocked by Gatekeeper. :˜(

I appreciate the push for an official rust frontend. I've personally been migrating (slowly) to using nix to manage my Mac's software, but there are a ton of limitations which lead me to rely on homebrew anyway. The speed ups will be appreciated.

Wait a minute, Homebrew is slow? I thought most of the time it takes for me is downloading and installing. I haven't noticed slowdowns anywhere else, even for the ones mentioned.

In it's current form, homebrew is amazing. It's not that slow and recent updates have made it really good to use. May I know the reasons for a Rust rewrite?

> Compatible” is doing a bit of work here when it also means “implicitly relies on Homebrew’s CDN, CI, packaging infrastructure and maintainers who keep all this running”.

This is literally what "compatible" means, how else did you expect then to frame it?

That is great news! Would be even more awesome if it was being ported to a more approachable language like Go or Zig, or somehow rearchitected in Ruby, but I take it that ship has sailed long ago. Ruby -> Rust is a brutal move.

I'm really interested to learn more about the work on the official Rust frontend - do you have any links to share by chance?

McQuaid is correct in the strict sense, but the interesting question is what percentage of actually installed formulae use Ruby DSL features beyond archive extraction and path manipulation. My guess is it's a small minority of what most developers have on their machines.

The real compatibility test isn't "runs all Homebrew formulae" — it's "runs the 15-20 formulae each developer actually uses." A tool that handles those correctly and fails clearly on edge cases is more useful in practice than a technically complete implementation that's slower.

What's missing from this thread is any data on that surface area, not more benchmark numbers.

Makes no sense, the wording suggests it can use Homebrew's backend, not that it's a complete alternative to Homebrew. Nobody is confused about that.

thank you for all you (and your co-maintainers) do for the community!

> Homebrew is working on an official Rust frontend that will actually have full compatibility. Hopefully this will help share effort across the wider ecosystem.

Where can I read more on this effort?

What drove the choice to use Rust for an official frontend?

> I’ve never sat there thinking “If this was only 2 seconds faster…” while doing an update

I definitely have thought something along those lines (mostly when I go to install a small tool, and get hit with 20 minutes of auto-updates first).

Pretty sure I also will not be adopting this particular solution, however

If you use the Homebrew module for Nix-Darwin, running `brew` against the generated brewfile becomes the slowest part of a `darwin-rebuild switch` by far. In the fast cases, it turns something that could take 1 second into something that takes 10, which is definitely annoying when running that command is part of your process for configuration changes even when you don't update anything. Homebrew no-ops against an unchanging Brewfile are really slow.

I've been a lightweight homebrew user for many, many, many years now. I just use it to download or update a thing I need, once every 3-6mo.

It constantly blows my mind how insanely long it takes just to do a few simple things on the fastest hardware I've ever owned in my life.

Agreed here. The speed bottleneck I run into is simply that there's often a lot of packages that need updating, so there's a lot to download. And if anything needs to be compiled from source then the time that takes will dominate (though I think everything I currently run is thankfully pre-built)

Brew definitely used to be a lot slower, and I used to find it very tedious. I feel like they've done a reasonably good job in improving that over the years though (with the switch to distributing binaries by default being a huge win in terms of speed). I have to wonder if stuff like this is more due to lingering feelings from before combined with the easy access to vibe coding tools. If LLM coding came a few years earlier, maybe projects like this one would have made more sense to me.

If I have to deal with even the mention of another package manager in the cross-platform dev ecosystem I am going to snap

The same criticism has been said of Deno and Pnpm and bun, and yet, despite all these years since their respective releases, node and npm remain slower than all three options.

Horses for courses, but I've stopped using brew 'cuz it's too slow, so this might bring me back!

Edit: no, it won't...

My brew update/upgrade takes forever

I've wanted brew to be faster. It would be a nice QoL for me.

I definitely have felt this. Homebrew is slow.

However, this is a vibe-coded app, with around 30 commits per day, which I don't let install packages on my machine.

See also: asdf and mise

https://github.com/asdf-vm/asdf/issues/290#issuecomment-2365...

To be fair, Apple stopped providing security fixes for Mojave ~4+ years ago, and there have been 7 or 8 new os releases since then…

I don’t think it’s reasonable to expect an open source project to support everything

Run Linux on it. Apple has cut that OS off anyway. Would be safer security wise to have an OS that's updated

Yes MacPorts is the way. I switched after a new MacOS release meant mine was too old - brew update uninstalled a bunch of stuff I had been using then it stopped and let me know.

There's also https://github.com/dortania/OpenCore-Legacy-Patcher for the adventurous.

What did you find surprising about MacPorts? And if you had any gripes to share, what would they be?

You could use the OpenCode legacy patcher to upgrade to v15/Sequoia: https://dortania.github.io/OpenCore-Legacy-Patcher/

Zerobrew looks mature, I'll check it out.

Btw, I noted this:

> Zerobrew is experimental. We recommend running it alongside Homebrew rather than as a replacement, and do not recommend purging homebrew and replacing it with zerobrew unless you are absolutely sure about the implications of doing so.

So I guess its fine to run this alongside Homebrew and they don't conflict.

And zerobrew, like the original Homebrew, is compatible with Linux.

It appears that Nanobrew is not.

I care about the light-weight efficiency of these new native code variants much more when I want to use brew on some little Linux container or VM or CI, than I do for my macOS development machine.

>Install zerobrew via brew as per the official instructions.

>Immediately get an error saying the install path is too long and needs to be fixed as /opt/zerobrew/prefix is too many bytes.

Yeah gonna need some work.

> I install most of my packages from a Brewfile, which itself is Ruby code.

Same. Whatever happens, the new version should support Brewfile.

This thread invigorated my interest in Nix to manage my Mac environment.

I already have a Brewfile in my dotfiles stored in git, but wanted a way to setup all the little things on my Mac like trackpad settings, dock settings, file associations, etc. nix-darwin is the obvious solution.

Gave the task to ChatGPT and it came back saying it's a good way to get started, but then offered a middle-ground of an idempotent script to set things up. So I investigated the latter, and after a couple of minutes I now have a setupmac() function in my .bash_profile (yeah I use bash) which mostly consists of a bunch of 'defaults' commands and a few other things, and now continue with brew for managing software and setupmac() to setup everything else, and of course manually manage my dotfiles for ghostty/nvim.

I wish I had this earlier, because I just set myself up on 3 different Macs in the last week or so. I'm also glad I don't need to learn a new language and tooling for something pretty simple. Everything is a bit disjointed and not as automated as a proper nix setup and doesn't have that fidelity that nix has, but it's straight-forward, compact in that it sits in my brain easily, and easy to execute.

HOMEBREW_NO_AUTO_UPDATE=1 will disable this (annoying) behavior. Set it in your bashrc or zshrc.

(report card for an0malous): "Does not play nice with other students."

It uses the Homebrew API and uses its own dependency resolver and linker to pull Homebrew's precompiled packages.