Live data from Hacker News

Nanobrew: The fastest macOS package manager compatible with brew

nanobrew.trilok.ai

151–156 of 156 posts

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

#151
post #57

Earlier quoted context omitted.

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) - syntheti…

Thank you for the answer now it made more clearer, at least for me, on what you meant.

And to be fair, when I was at 4.x version, 90% of the time I was in the happy path, my "being slow" issue was when download speeds got really bad, sometimes caused by my ISP, so my end.

As others mentioned, homebrew is a great piece of software, thank you, not only you but everyone who maintains it.

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

#152

What would be great is a Homebrew-compatible system that doesn't cut off support for older machines. I have a 3.8 GHz Quad core i5 iMac that still crushes, yet Homebrew has determined that I'm just too old and icky[1] to work with anymore. I had to move over to MacPorts, which is surprisingly nice, but I still miss brew. Yea, I know. It's open source. They can do what they want. Still sucks. 1: https://docs.brew.sh/S…

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

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

#153
post #57

Earlier quoted context omitted.

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) - syntheti…

While I have some vague recollection of homebrew feeling slow in the past I don't know when - I want to say well before Nov 2025. And recently absolutely no such feeling, and great features like auto update handling, etc just working. It's really good stuff.

Python has powered Linux package management to reasonable result for a long time, Python itself is ironic for having tricky platform constraints that ended up being best solved with uv's excellent rust solver. For homebrew I would personally not stress over a Rust frontend - but if it keeps some of the FUD out then maybe it's worth it!

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

#154
post #133

Earlier quoted context omitted.

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?

I don't recall ever having something break from upgrading it in homebrew, but I do recall having issues in the past from having things outdated without realizing it (usually stuff that wasn't getting upgraded by my package manager, e.g. VS Code being months out of date without me realizing and therefore not working with an extension the company I was working at had developed).

On the average day, I get maybe two or three package upgrades from it. Sometimes, they're packages that I'm extremely grateful to have updates for immediately (like rust-analyzer), and other times they're things that I don't use very often (or don't use directly), so I wouldn't likely remember to upgrade them at all if I didn't make a habit of it.

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

I felt like I was pretty clear in my original comment that I didn't know whether other people upgraded as often as me or not. That being said, it does sound like you've been having an experience you're unhappy with, and I'm not, so I'm not sure why you're so confident that the way I'm using it is weird. It's very possible that it would not end up being something you or others are happy with, but it's more weird to me that you think this is such a huge deal when it seems like the most obvious way in the world to use a package manager to me.

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

#155
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 have definitely wished that Homebrew would not wait for all packages to be downloaded before pouring them. It's nice that downloads happen in parallel (didn't always used to be the case iirc), but it feels like the pouring could also be done in the same parallel workflow.

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

#156

It might be good to explain how this differs from zerobrew [0], which is trying to accomplish the same thing [0] https://github.com/lucasgelfond/zerobrew

I also have a solution mostly for myself but others are welcomed to it: https://zieka.github.io/bru/

Outlined some differences here between the various projects; might be useful: https://github.com/zieka/bru?tab=readme-ov-file#how-bru-comp...

Post reply on HN