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 have full compatibility. Hopefully this will help share effort across the wider ecosystem.
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.
Yeah I don't know why people are saying that speed doesn't matter. I use Homebrew and it is slow.
It's like yum vs apt in the Linux world. APT (C++) is fast and yum (Python) was slow. Both work fine, but yum would just add a few seconds, or a minute, of little frustrations multiple times a day. It adds up. They finally fixed it with dnf (C++) and now yum is deprecated.
Glad to hear a Rust rewrite is coming to Homebrew soon.
> Yeah I don't know why people are saying that speed doesn't matter. I use Homebrew and it is slow
Because how often are you running it where it's not anything but a opportunity to take a little breather in a day? And I do mean little, the speedups being touted here are seconds.
I have the same response to the obsession with boot times, how often are you booting your machine where it is actually impacting anything? How often are you installing packages?
Do you have the same time revulsion for going to the bathroom? Or getting a glass of water? or basically everything in life that isn't instantaneous?
One of the reasons I switched to arch from debian based distros was precisely how much faster pacman was compared to APT -- system updates shouldn't take over half an hour when I have a (multi)gigabit connection and an SSD.
It was mostly precipitated by when containers came in and I was honestly shocked at how fast apk installs packages on alpine compared to my Ubuntu boxes (using apt)
pacman is faster simply because it does less things and it supports less use cases.
For example pacman does not need to validate the system for partial upgrades because those are unsupported on Arch and if the system is borked then it’s yours to fix.
I would guess this change builds on the existing json endpoints for package metadata but that the Ruby DSL is remaining intact.
I think how to marry the Ruby formulas and a Rust frontend is something the Homebrew devs can figure out and I'm interested to see where it goes, but I don't really care whether Ruby "goes away" from Homebrew in the end or not. It's a lovely language, so if they can keep it for their DSL but improve client performance I think that's great.
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.
Sorry, examples of what? Package managers that present themselves as replacements for other package managers? Or package managers that aren't compatible with the registry they're supposed to be compatible with? Your use of scare quotes is confusing.
pnmp, npm, yard all have different lockfiles, all use the same registry format (and the same registry itself), all try to stay compatible in other ways.
You won't be having situation where one uses yarn and someone uses pnpm on the same project tho.
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.
I still think that's entirely fair for a power user tool like homebrew. With the upgrade rates of macOS that probably means that's 98% of the users would be covered. Expecting an open source project to accept bug requests from a bigger variety of versions that then would need test devices on these versions to replicate issues sounds unrealistic. Bigger companies, or Apple itself I would hold to much higher standards when it comes to that.
That makes no sense then. A power user may still want to run older OS versions for a reason. Take the training wheels off it and then it'll be a power user tool.
> A power user may still want to run older OS versions for a reason.
No doubt there are edge cases like that, but I don't fault a project for not catering to the < 1% of users who would fall into that bucket and would probably be the ones that cause trickier support cases. These would maybe also be the user that could just install it without homebrew then, it's not like homebrew is the only way to install software.
brew used to say, more or less, "This OS is old and unsupported. Don't submit bug reports. If you have problems, too bad. If you submit a PR to fix something, we might merge it". Fair enough, right? Now it just says, "Go fuck yourself, grandpa."
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.
Sure, but this might win you a couple of years max. Homebrew's "Support Tiers" page, which I linked, also addresses OCLP users, going so far as to specify a minimum Intel architecture. So, even if you use OCLP to allow support for newer OS versions, eventually your CPU architecture will be too old and you're back in Tier 3.
Also, the writing is on the wall: Ultimately, Homebrew will be ARM-only, once Apple's legacy support becomes ARM-only. At which point it's game-over for Intel Macs.
Homebrew solves the "availability of software" problem in the Mac ecosystem, but it does not solve the "Need to stay on the new hardware treadmill" problem.
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.
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).
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
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.
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)
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.
Yeah, but do they work? Last time I gave bun a chance their runtime had serious issues with frequent crashes. Faster package installation or spin-up time is meaningless if it comes at the cost of stability and compatibility.
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?
I wish I could remember the details -- I know I got annoyed with things being slow and when I got a new computer decided to go the no-homebrew route. I'm using nix, and it seems fine so far, but I also really don't understand it at all, which is a little concerning. :-)
I naively assumed it would work on the already installed homebrew packages. No such luck.
After installing, 'nb list' and thus eg. 'nb outdated' will yield the empty list!
I have absolutely no use for a competing homebrew installation that is mostly compatible ..
This might be a good thing for homebrew to adopt for the download/install process, but if it doesn't include a ruby interpreter, I have a hard time seeing how it's going to be compatible with anything but searching and installing bottles. I install most of my packages from a Brewfile, which itself is Ruby code.
> 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.
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.
I've been looking for something like this, especially to use only with casks now that Homebrew has removed support for not adding the quarantine bit. Looking forward to giving it a try!
what happens if I test this tool by installing some packages and then remove (the tool)? will I still be able to use Homebrew to manage these new packages?
The current version of brew has a flaw where the installer can't install isolated dependency trees in a sterile manner. If you have packages A, B, C, and D that all have updates, and assuming A,B,C depend on each other and come out to a total of say 1MB, and D is 1000MB, brew works in a MapReduce manner where it will attempt to finish downloading everything in parallel (even though the real bottleneck is D) before doing any installation.
Since the first 3 has no dependency on D, a better way would be to install them in parallel while D is still downloading.
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 have full compatibility. Hopefully this will help share effort across the wider ecosystem.
> 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.
I didn't know about the pending, official Rust frontend! That's very interesting.
It's like yum vs apt in the Linux world. APT (C++) is fast and yum (Python) was slow. Both work fine, but yum would just add a few seconds, or a minute, of little frustrations multiple times a day. It adds up. They finally fixed it with dnf (C++) and now yum is deprecated.
Glad to hear a Rust rewrite is coming to Homebrew soon.
Because how often are you running it where it's not anything but a opportunity to take a little breather in a day? And I do mean little, the speedups being touted here are seconds.
I have the same response to the obsession with boot times, how often are you booting your machine where it is actually impacting anything? How often are you installing packages?
Do you have the same time revulsion for going to the bathroom? Or getting a glass of water? or basically everything in life that isn't instantaneous?
It was mostly precipitated by when containers came in and I was honestly shocked at how fast apk installs packages on alpine compared to my Ubuntu boxes (using apt)
For example pacman does not need to validate the system for partial upgrades because those are unsupported on Arch and if the system is borked then it’s yours to fix.
Anyway the python program would call into libsolv which is implemented in C.
dnf5 is much faster but the authors of the program credit the algorithmic changes and not because it is written in C++
dnf < 5 was still performing similarly to yum (and it was also implemented in python)
I think how to marry the Ruby formulas and a Rust frontend is something the Homebrew devs can figure out and I'm interested to see where it goes, but I don't really care whether Ruby "goes away" from Homebrew in the end or not. It's a lovely language, so if they can keep it for their DSL but improve client performance I think that's great.
(Just kidding, thank you for creating homebrew and your continued work on it!)
You cannot really be compatible with this unless you run the Ruby as the install scripts could do whatever arbitrary computations
In reality most recipes contain a simple declarative config but nothing stops you from doing Ruby in there.
Hence to achieve total compatibility one would need to run Ruby
> nanobrew
> The fastest macOS package manager. Written in Zig.
> 3.5ms warm install time
> 7,000x faster than Homebrew · faster than echo
It presents itself as an alternative to Homebrew.
You won't be having situation where one uses yarn and someone uses pnpm on the same project tho.
Yea, I know. It's open source. They can do what they want. Still sucks.
1: https://docs.brew.sh/Support-Tiers
I don’t think it’s reasonable to expect an open source project to support everything
That makes no sense then. A power user may still want to run older OS versions for a reason. Take the training wheels off it and then it'll be a power user tool.
No doubt there are edge cases like that, but I don't fault a project for not catering to the < 1% of users who would fall into that bucket and would probably be the ones that cause trickier support cases. These would maybe also be the user that could just install it without homebrew then, it's not like homebrew is the only way to install software.
There's also https://github.com/dortania/OpenCore-Legacy-Patcher for the adventurous.
Also, the writing is on the wall: Ultimately, Homebrew will be ARM-only, once Apple's legacy support becomes ARM-only. At which point it's game-over for Intel Macs.
Homebrew solves the "availability of software" problem in the Mac ecosystem, but it does not solve the "Need to stay on the new hardware treadmill" problem.
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 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).
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.
Never had any issues.
Edit: no, it won't...
https://github.com/asdf-vm/asdf/issues/290#issuecomment-2365...
After installing, 'nb list' and thus eg. 'nb outdated' will yield the empty list! I have absolutely no use for a competing homebrew installation that is mostly compatible ..
Same. Whatever happens, the new version should support Brewfile.
[0] https://github.com/lucasgelfond/zerobrew
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.
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.
Do they use some kind of Ruby parser to parse formulae?
[0]: https://github.com/Homebrew/homebrew-core/blob/26-tahoe/Form...
nb info --cask codex-app
nb: formula '--cask' not found
nb: formula 'codex-app' not found
Since the first 3 has no dependency on D, a better way would be to install them in parallel while D is still downloading.