Makes no sense, the wording suggests it can use Homebrew's backend, not that it's a complete alternative to Homebrew. Nobody is confused about that.

▲

akdev1l 2 days ago | parent | next [-]

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

▲

saghm 2 days ago | parent [-]

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.

	▲	akdev1l 2 days ago \| parent [-]
		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)

▲

nozzlegear 2 days ago | parent | prev [-]

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.

▲

halapro 2 days ago | parent | next [-]

There are many such examples for npm as well: many "compatible" managers, one registry.

▲

nozzlegear 2 days ago | parent [-]

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.

	▲	0x457 2 days ago \| parent [-]
		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.

▲

2 days ago | parent | prev [-]

[deleted]