Nanobrew: The fastest macOS package manager compatible with brew

Post by SOLAR_FIELDS » Tue, Mar 24, 2026, 3:05 PM UTC

pxc wrote: post #14

mikemcquaid wrote: post #6

If it doesn’t ever execute Ruby: it cannot be compatible with Homebrew. “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”. There’s a new vibe coded Homebrew frontend with partial compatibility and improved speed every few weeks. Homebrew is working on an official Rust frontend that will actually hav…

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.

Post by ryandrake » Tue, Mar 24, 2026, 3:19 PM UTC

Post by slackfan » Tue, Mar 24, 2026, 3:25 PM UTC

joshstrange wrote: post #21

swiftcoder wrote: post #15

Earlier quoted context omitted.

> 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

But you can turn that behavior off, IIRC it tells you the environment variable to set if you don’t want it to do that every time it runs. I agree it’s annoying, but I haven’t turned it off because it’s only annoying because I’m not keeping my computer (brew packages) up-to-date normally (aka, it’s my own fault).

Post by atonse » Tue, Mar 24, 2026, 3:30 PM UTC

mikemcquaid wrote: post #6

If it doesn’t ever execute Ruby: it cannot be compatible with Homebrew. “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”. There’s a new vibe coded Homebrew frontend with partial compatibility and improved speed every few weeks. Homebrew is working on an official Rust frontend that will actually hav…

Post by never_inline » Tue, Mar 24, 2026, 3:34 PM UTC

noahbp wrote: post #29

drob518 wrote: post #7

This feels like a solution looking for a problem. I have a couple hundred brew packages on my system and I’ve never sat there thinking “If this was only 2 seconds faster…” while doing an update. I’m sure the Homebrew folks could mine this for a few ideas of how to further optimize brew, but I don’t think I’ll be adopting it anytime soon. Compatibility is more important than speed in this case.

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.