Live data from Hacker News

Nanobrew: The fastest macOS package manager compatible with brew

nanobrew.trilok.ai

131–140 of 156 posts

Re: Nanobrew: The fastest macOS package manager compatible with brew

#131

I've found brew so painful that I switched to nix. Nix unfortunately is painful in its own way. However, I recently discovered devbox which is a wrapper around nix. It works really well as a package manager. Just run "devbox global add "

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.

Re: Nanobrew: The fastest macOS package manager compatible with brew

#133
post #121
post #90

Earlier quoted context omitted.

I'm not sure if I just have way fewer things installed than most people or I just update more often, but I haven't experienced anything like this for years. I run `brew upgrade` probably around once every (work)day, usually right before doing a git pull or something, and then I'll quickly look at a couple emails or slack messages, and then it's always done by the time I switch back

What? Why are you running brew upgrade every day?

To upgrade my packages? I'm not sure I understand the question. That's how I use pretty much all of my systems that have package managers.

Re: Nanobrew: The fastest macOS package manager compatible with brew

#134
post #133
post #121

Earlier quoted context omitted.

What? Why are you running brew upgrade every day?

To upgrade my packages? I'm not sure I understand the question. That's how I use pretty much all of my systems that have package managers.

But why do you want daily upgrades? Most of us want to wait a little while for the bugs to be worked out of fresh releases. And hey, if everything is working today... why would I want to risk potential breaking changes?

Re: Nanobrew: The fastest macOS package manager compatible with brew

#135

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…

> 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?

Re: Nanobrew: The fastest macOS package manager compatible with brew

#136

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…

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?

Re: Nanobrew: The fastest macOS package manager compatible with brew

#137
post #35

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…

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

I also think it's a bit unfortunate, but I can also see the side of not wanting to support things that technically make macos less secure

Re: Nanobrew: The fastest macOS package manager compatible with brew

#138
post #135

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…

> 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?

It’s more of an alternative CLI for Homebrew itself, not an alternative that happens to be compatible.

Re: Nanobrew: The fastest macOS package manager compatible with brew

#139

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…

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.

Re: Nanobrew: The fastest macOS package manager compatible with brew

#140
post #57
post #54

Earlier quoted context omitted.

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

Thank you, his arguments totally makes sense, only the part that makes me icky is: > There’s a new vibe coded Homebrew frontend with partial compatibility and improved speed every few weeks. People are free and probably do this because it is slow. Alternatives often are not a bad thing.

Indeed, everyone's free to do what they want, that's the beauty of open source.

I have zero issues with people vibe coding alternative Homebrew frontends, it's good for the ecosystem for there to be more experimentation.

What I take objection to is when one or more of these happen:

- incorrect compatibility claims are made (e.g. if you're not running Ruby, no post-install blocks in formulae are gonna work) - synthetic benchmarks are used to demonstrate speed (e.g. running `brew reinstall openssl` in a loop is not a terribly representative case, instead a e.g. cold `brew upgrade` of >10 packages would be). to be clear, I'm sure most of these projects are faster than Homebrew in fair benchmarks too! - incorrect claims about why Homebrew is slow are made (e.g. "we do concurrent downloads and Homebrew doesn't": true a year ago, not true since 5.0.0 in November 2025) - it's pitched as a "replacement for Homebrew" rather than "an alternative frontend for Homebrew" when it's entirely reliant on our infrastructure, maintainers, update process, API, etc.

Even on the above: of course people are free to do whatever they want! It's just at least some of the above hinders rather than helps the ecosystem and makes it harder rather than easier for us as a wider open source ecosystem to solve the problem "Homebrew is slow" (which, to be clear, it is in many cases).

Post reply on HN