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.
pxc 1 hours ago [-]
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.
SOLAR_FIELDS 41 minutes ago [-]
Wow they are finally getting away from Ruby? Awesome. The speed will be a nice boon
atonse 15 minutes ago [-]
Heyyyy, who are you to tell us what is and isn't compatible with homebrew?
(Just kidding, thank you for creating homebrew and your continued work on it!)
ryandrake 26 minutes ago [-]
Would 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.
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.
swiftcoder 1 hours ago [-]
> 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
joshstrange 41 minutes ago [-]
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).
swiftcoder 53 seconds ago [-]
I'd be much happier if it were on a background job, than arbitrarily running when I invoke a command
slackfan 20 minutes ago [-]
Terrible default behavior is a great reason to abandon a software package.
bombcar 47 minutes ago [-]
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".
SOLAR_FIELDS 41 minutes ago [-]
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
pxc 1 hours ago [-]
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.
noahbp 14 minutes ago [-]
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.
never_inline 11 minutes ago [-]
Well, pnpm solves the storage issue, which is a more pressing reason to use it. (I don't know about deno/bun)
mproud 33 minutes ago [-]
My brew update/upgrade takes forever
dilap 1 hours ago [-]
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...
drob518 1 hours ago [-]
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?
manlymuppet 6 minutes ago [-]
If we get the Bun-ification of every package manager and language ecosystem that would be an awesome thing. This is a great trend.
chuckadams 2 hours ago [-]
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.
luizfelberti 1 hours ago [-]
It might be good to explain how this differs from zerobrew [0], which is trying to accomplish the same thing
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.
alsetmusic 51 minutes ago [-]
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.
tantalor 22 minutes ago [-]
And why does speed matter in this case?
kassadin 1 hours ago [-]
Do you choose compatibility or speed?
nb info --cask codex-app
nb: formula '--cask' not found
nb: formula 'codex-app' not found
an0malous 2 hours ago [-]
Does it reinstall postgres for every package install?
ericcholis 2 hours ago [-]
HOMEBREW_NO_AUTO_UPDATE=1 will disable this (annoying) behavior. Set it in your bashrc or zshrc.
8 minutes ago [-]
mitchitized 2 hours ago [-]
(report card for an0malous): "Does not play nice with other students."
an0malous 1 hours ago [-]
It's true :')
pxc 1 hours ago [-]
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!
1 hours ago [-]
Rendered at 15:45:48 GMT+0000 (Coordinated Universal Time) with Vercel.
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.
I didn't know about the pending, official Rust frontend! That's very interesting.
(Just kidding, thank you for creating homebrew and your continued work on it!)
Yea, I know. It's open source. They can do what they want. Still sucks.
1: https://docs.brew.sh/Support-Tiers
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).
Edit: no, it won't...
[0] https://github.com/lucasgelfond/zerobrew
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.
nb info --cask codex-app
nb: formula '--cask' not found
nb: formula 'codex-app' not found