Live data from Hacker News

Nanobrew: The fastest macOS package manager compatible with brew

nanobrew.trilok.ai

11–20 of 156 posts

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

#11
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.

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.

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

#12
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.

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

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

#14

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.

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

#15
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.

> 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

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

#16
post #12
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.

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

Agreed on horses for courses. Different people have different tolerances. And yea, all things being equal, faster is better, but they are almost never equal. If you don’t mind me asking, what does “too slow” mean for you in this context? Do you have a particularly complex setup? And what do you use now as an alternative and how has that impacted the update speed?

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

#18
I'm not a Python dev, but I appreciate the motivation uv has inspired across other package managers. I tried another brew replacement called zerobrew last month. It installed packages to a different directory from homebrew, so I didn't actually test drive after seeing that. Regardless, I look forward to the competition pushing mainstream tools to improve their performance.

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

#19
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.

> 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

I've never thought "only 2 seconds faster" - I've certainly thought "why is this taking half the time it takes Gentoo to recompile an entire server".

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

#20
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.

> 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

FWIW this seems to have improved in recent years. Back in the dark times of non parallelized downloads I would purposefully wait to end of day and fire the thing off before leaving
Post reply on HN