Live data from Hacker News

Show HN: Homebrew 6.0.0

brew.sh

161–170 of 380 posts

Re: Show HN: Homebrew 6.0.0

#161

Does anyone know of a good comparison of the process to add a package to the system? I've used multiples of these sorts of user-land package managers and always find tools that aren't in the repositories that I have to install manually. It'd be great to just add these tools to an existing package manager but I've never seen this aspect of these package managers compared.

Comparison of which managers? Adding package to homebrew is straightforward, except that it has a lot of (reasonable?) requirements to make it right. Basically, you make a PR with a "formula" to their main repo from your branch. Formulas are ruby programs. LLM can do it easily, and such code is accepted if correct.

Homebrew, mise, flox, devenv are the first ones I can think of.. Arch Linux's AURs get an honorary mention as they are used in the similar way on that distro and Arch + distrobox gets the same results. A quick search shows there are many others but it doesn't look like a comparison exists for this area and I'm getting OK results out of AI comparisons. I'll just dig into it that way.

Re: Show HN: Homebrew 6.0.0

#162

I have switched my full OS-level dev env to https://mise.jdx.dev/ from Homebrew+pipx+npm, initially as an experiment but found out that it actually works amazingly well. Many things get installed directly from GitHub releases or a corresponding package manager (uv, pnpm, go get ...), zero glue code to "repackage", zero version lag. You can install any arbitrary version of a package, even multiple ones at once, and dy…

I did the same but with Nix.

me too but feels like bringing bazooka to a watergun fight. might go back to brew

Re: Show HN: Homebrew 6.0.0

#163
post #7

Thanks for the update. Is there any chance we can get some kind of cooldown mechanism in Homebrew? The only people I want to trust to quickly ship new code to my machine are Apple and my browser (which handles more untrusted input than anything else). For everything else (vscode and its extensions, npm, homebrew, and all the apps that self-update), I prefer to err on the side of waiting a few days. Some exceptional 0…

It's all rolling release, but Homebrew maintainers have to bump the version, not the software author (unless they put in a PR to Homebrew core or publish their own Tap). What does Arch do here?

That’s not quite true. A recipe can specify a URL to check for a new version, and the homebrew automation will periodically check it. If there’s a new version, it automates the version bump.

I used that for a package my company publishes, and neither we nor any other human AFAIK ever manually update it in homebrew, yet the newest version is always installable there.

Re: Show HN: Homebrew 6.0.0

#164

Earlier quoted context omitted.

> quite annoying It's also quite stable, which you'd think more people would prize given the recent and on-going supply chain attacks.

Stable as in unchanging, sure. Stable can also mean "you get to keep all the bugs present in this version for the next 4+ years"

Or worse, the kernel moves beyond the package in the repo so a year and a half later it doesn't even work anymore.

VirtualBox is really bad about this.

Re: Show HN: Homebrew 6.0.0

#166

The deprecation of Intel support is agressive! Every Mac enthusiast I know who uses a Mac as a server uses their old machines, which are pretty much all Intel. We'll lose support from you guys a year before Apple! I know supporting Intel is an ordeal and a choice, but I'm firmly on the camp that Homebrew should find a way to maintain Intel support as long as possible.

A saving grace is they're perfect for linux distros.

Re: Show HN: Homebrew 6.0.0

#167
post #131

Earlier quoted context omitted.

Given the recent dramatic uptick in vulnerability discoveries, it's also prone to being quite insecure...

LTS still typically get security updates. That's what the support in long term support means.

This gets thrown around a lot, but it's not entirely true. Depending on the particular distro, only certain core packages are likely to get updates on LTS releases. Non-core packages may just get left to rot until the next LTS release. Specifically Ubuntu follows this. A lot of their non-core packages just get imported from Debian and then just sit unmaintained until next release (this goes doubly if not using Ubuntu Pro).

Re: Show HN: Homebrew 6.0.0

#168
macOS 27 (Golden Gate) drops Intel support, so ... in September 2027, macOS Intel x86_64 will be unsupported entirely and all related code deleted.

hmm... that's too bad.

Re: Show HN: Homebrew 6.0.0

#169

Earlier quoted context omitted.

Nix is also worth checking out, even if the Darwin packaging is a bit flaky. I really appreciate having cross-platform devshells when I have to alternate between Mac and Linux on a regular basis.

Mise is also cross-platform, we actually use it at work for projects we develop locally on macOS, then build in CI on Linux -- it even supports multiplatform lockfiles. I had a few tries with Nix but it's a lot to wrap your head around, Mise is simple to "just try".

Nix has a high learning curve. I now use Devbox [0] as it hides all the complexity of Nix while still giving all the benefits.

Now I install far more packages via devbox (or devbox global) than I do via HomeBrew (on osx) or pacman (on arch).

[0] - https://www.jetify.com/devbox

Post reply on HN