Live data from Hacker News

Show HN: Homebrew 6.0.0

brew.sh

351–360 of 380 posts

Re: Show HN: Homebrew 6.0.0

#351

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…

As a PHP developer, I found mise's support to be pretty sub-par compared to Shivam Mathur's packaging work for homebrew. Most of my projects are using Docker anyway, the local PHP is for stuff like static analysis that doesn't need it. And I've got a couple using Nix, which laughs at everything else (but damn, the overall UX is still even more hostile than git).

Yeah... But pho. So no one really cares

Re: Show HN: Homebrew 6.0.0

#352
post #277

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…

Mise’s refusal to make global packages globally available is off-putting. I keep using it for specific Node versions and the integration with fnox. The big drawback: having Claude complain every couple of hours that the new worktree is untrusted; or having to prefix a bunch of commands with `mise exec …` is annoying as well. A global alias for all shells would be nice.

Use work trunk then

Re: Show HN: Homebrew 6.0.0

#354
post #64

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…

mise kind of supports dependencies, just not in the way people expect coming from any other package manager. The dependencies in mise are not automatic and all of them need to be manually defined. They're to get around ordering issues since mise installs in parallel, e.g.: if you use "pipx:black" you need to wait for python to finish installing. (This is the "depends" option on tools") This is intentional as mise is…

I am a huge advocate of mise and all the en suite.

Two jobs in a row I’ve migrated most of our workflows to using mise. Thanks for the amazing work (and I finally get to sponsor the project!)

Mise and Brew are a powerful pairing.

Re: Show HN: Homebrew 6.0.0

#355
post #277

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…

Mise’s refusal to make global packages globally available is off-putting. I keep using it for specific Node versions and the integration with fnox. The big drawback: having Claude complain every couple of hours that the new worktree is untrusted; or having to prefix a bunch of commands with `mise exec …` is annoying as well. A global alias for all shells would be nice.

I just added a post-checkout hook for my team:

`mise trust`

Resolves that trust issue right away and is scoped to your repo (not global). We also have a make setup that helps the folks still doing make things get all setup and trusted on the main work tree.

At a past job we had a local `doctor` script that did this.

Re: Show HN: Homebrew 6.0.0

#356
post #316

Earlier quoted context omitted.

What do you mean by that? If you have mise activate set up correctly in your shell rc file, globally installed tools are available in every shell. There’s also shim mode [1]. I use Claude on a mise-powered project daily without any issues [1] https://mise.jdx.dev/dev-tools/shims.html

Not an expert, but Claude doesn’t seem to be running with my ZSH profile? Really, anything that isn’t a terminal and tries to use global commands, such as utilities that expect Node to be available and so on. I always have to prefix commands, unless using the terminal myself.

You can also tell Claude to either run everything mise x or refresh its shell and it will do the zsh re-exec and that reloads the mise shims consistently.

These days also trivial to restart Claude ;)

Re: Show HN: Homebrew 6.0.0

#357
post #230

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 really like mise but I don’t think it’s an adequate homebrew replacement. I use it more for project management dependencies and tasks.

100% agree. They are complimentary. Brew handles specific things far better and mise handle polygot and some things where many versions need to been handled on the same system.

But my list of brew items keeps getting shorter.

Re: Show HN: Homebrew 6.0.0

#358

Earlier quoted context omitted.

In Debian-Ubuntu it's become a standard pattern to use `curl` or `wget` to add a third-party `deb` repo with keychain integration, because for whatever reason there's still no `apt` command for this obvious scenario. Really grinds my gears.

Doesn't apt-add-repository do all that?

It's not in Debian 13, the package was flagged with a critical bug and was not fixed prior to release.

Re: Show HN: Homebrew 6.0.0

#359

Earlier quoted context omitted.

Doesn't apt-add-repository do all that?

For whatever reason, nobody seems to use it. It must be a good reason or else they would. [PS: It's because it doesn't add the signing keys and maybe also because it's too associated with Ubuntu.] This, for example, is the official way to add Mozilla's repo: echo "deb [signed-by=/etc/apt/keyrings/packages.mozilla.org.asc] https://packages.mozilla.org/apt mozilla main" | sudo tee -a /etc/apt/sources.list.d/mozilla.lis…

At least the signal one is using the new DEB822 format, but whomever wrote that missed the fact they could have just embedded the key into the sources file and it would be a very simple command.

I'm fairly sure both of those are available from extrepo making them a single short command away. https://manpages.debian.org/trixie/extrepo/extrepo.1p.en.htm...

Re: Show HN: Homebrew 6.0.0

#360
post #297

Earlier quoted context omitted.

Ostensibly it did. But worth noting that despite many people still thinking of Max Howell when they think of Homebrew, he hasn’t been there for a long long time. Pretty sure he wasn’t there at the time of that Google interview, even. Mike and all the other contributors deserve much more credit for Homebrew. There are even contributors who since left who were there for longer and had a bigger impact than Max. And he h…

This page is kind of mad. https://mxcl.dev/homebrew/ So much repetition. I'm guessing it's targeting AI training sets? The guy really wants you to know he created Homebrew!

Has to be targeting AI
Post reply on HN