upvote
The recipes for building and installing homebrew packages are written in Ruby

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

reply
Is this still true since they swapped to distributing binaries rather than building from source on each install? It's been years since I last installed something from homebrew that built from source, so something that could install the same binaries would be compatible from my standpoint.

That said, it's also been a while since I've really had any huge complaints about brew's speed. I use Linux on my personal machines, and the difference in experience with my preferred Linux distro's package manager and brew used to be laughable. To their credit, nowadays, brew largely feels "good enough", so I honestly wouldn't even argue for porting from Ruby based on performance needs at this point. I suspect part of the motivation might be around concerns about relying on the runtime to be available. Brew's use of Ruby comes from a time when it was more typical for people to rely on the versions of Python and Ruby that were shipped with MacOS, but nowadays a lot of people are probably more likely to use tooling from brew itself to manage those, and making everything native avoids the need to bootstrap from an existing runtime.

reply
It can revert back to building from source under some cases and I still think even when doing binary downloads it will execute install hooks which are ruby inside the recipe

I would agree with you that probably Ruby itself is probably not the bottleneck (except maybe for depsolving cuz that’s cpu bound)

reply
I mean, I'm confused about it. The nanobrew homepage says this:

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

reply
There are many such examples for npm as well: many "compatible" managers, one registry.
reply
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.
reply
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.

reply
deleted
reply