Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nanobrew: The fastest macOS package manager compatible with brew

nanobrew.trilok.ai

Post reply on HN
Print view View original

91–100 of 156 posts

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

#91

Post by brailsafe »

alwillis wrote: post #66
Xunjin wrote: 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.

Since I enabled HOMEBREW_DOWNLOAD_CONCURRENCY, downloads have improved for me to the point where download speed is no longer an issue.

Good to know! I was doing this with a hacky one-liner but wasn't aware of this flag. I think the sequential build/install process is the agonizing bit though.

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

#92

Post by wavemode »

akdev1l wrote: post #77
petcat wrote: post #41

Earlier quoted context omitted.

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 Homebre…

yum was slow not because of python but because of the algorithm used to solve dependencies 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)

> dnf I'm perhaps not properly understanding your comment. If the algorithmic changes were responsible for the improved speed, why did the Python version of dnf perform similarly to yum?

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

#94

Post by akdev1l »

saghm wrote: post #87
akdev1l wrote: post #79

Earlier quoted context omitted.

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

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 machine…

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)

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

#95

Post by akdev1l »

wavemode wrote: post #92
akdev1l wrote: post #77

Earlier quoted context omitted.

yum was slow not because of python but because of the algorithm used to solve dependencies 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)

> dnf I'm perhaps not properly understanding your comment. If the algorithmic changes were responsible for the improved speed, why did the Python version of dnf perform similarly to yum?

Because dnf4 used the same dependency resolution as yum but they revamped it in dnf5 (it was initially supposed to be a whole new package manager with a different name)

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

#96

Post by mpalmer »

Xunjin wrote: post #57
runjake wrote: post #54

Earlier quoted context omitted.

Context for those unaware: the commenter, mikemcquaid, is the project lead for Homebrew.

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.

I don't see where he said it's a bad thing, or even implied it. As I see it, he did imply that superlatives like THE FASTEST PACKAGE MANAGER aren't worth much in this environment.

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

#97

Post by phist_mcgee »

luizfelberti wrote: post #17

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

>Install zerobrew via brew as per the official instructions.

>Immediately get an error saying the install path is too long and needs to be fixed as /opt/zerobrew/prefix is too many bytes.

Yeah gonna need some work.

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

#98

Post by tzs »

OT: speaking of Homebrew, I made an incorrect assumption about it that eventually led to some problems. It was me being stupid, but I bet others have made the same mistake but not yet hit problems. Hence this comment.

My mistake was when I upgraded from my 2017 iMac (Intel processor) to an Apple silicon Mac at the start of 2024 and migrated via Time Machine I did not do anything extra specifically for Homebrew. I just assumed that as things got updated via the normal periodic Homebrew updates I run it would start grabbing the Apple silicon binaries for binary things it installed.

It turn out that is wrong. They made Apple silicon Homebrew kind of independent of Intel Homebrew. Intel Homebrew uses /usr/local and Apple silicon Homebrew uses /opt/homebrew. This allows having both native and Intel Homebrew installed at the same time if you need both.

The correct way to migrate from an Intel Mac to an Apple silicon Mac is to install Apple silicon Homebrew on the new Mac, and then install all the packages you want. Intel Homebrew works fine on Apple silicon Macs so you can use the Intel Homebrew that migrated via Time Machine to make the package list to use with Apple silicon Homebrew (or you can make it on the old Mac).

I only noticed this because I was trying to build something from source using some libraries that were installed via Homebrew and running into problems. An LLM was helping figure this out and it was telling me I might have to manually symlink those libraries from where they were in /opt/homebrew to where the build process for the thing I was building expected to find them and I didn't have a /opt/homebrew. The libraries were somewhere in /usr/local. I then noticed those libraries were not for Apple silicon, checked other things installed view Homebrew and saw nothing was for Apple silicon, and realized I had the wrong Homebrew.

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

#99

Post by derefr »

mikemcquaid wrote: post #6

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 hav…

> Homebrew is working on an official Rust frontend that will actually have full compatibility.

When you say "Rust frontend", is the vision that Homebrew's frontend would eventually transition to being a pure Rust project — no end-user install of portable-ruby and so forth?

If so (ignore everything below if not):

I can see how that would work for most "boring" formulae: formula JSON gets pre-baked at formula publish time; Rust frontend pulls it; discovers formula is installable via bottle; pulls bottle; never needs to execute any Ruby.

But what happens in the edge-cases there — formulae with no bottles, Ruby `post_install` blocks, and so forth? (And also, how is local formula development done?)

Is the ultimate aim of this effort, to build and embed a tiny little "Formula Ruby DSL" interpreter into the Rust frontend, that supports just enough of Ruby's syntax + semantics to execute the code that appears in practice in the bodies of real formulae methods/blocks? (I personally think that would be pretty tractable, but I imagine you might disagree.)

Post reply on HN