Live data from Hacker News

Show HN: Homebrew 6.0.0

brew.sh

341–350 of 380 posts

Re: Show HN: Homebrew 6.0.0

#341
post #220

Earlier quoted context omitted.

> Most Linux package managers cannot separate user-installed packages from system packages. What is the use case when someone would want to differentiate system/user installed package? Isn't it good things that they are the same - meaning once something is install - it is there regardless of how it got here.

Two reasons come to mind for me: 1. It's very common, especially in certain ecosystems like Python, for the system to depend on old versions of things in such a way that updating to modern versions will break your entire system, while at the same time you want to run something at the user level that depends on a newer version. The solutions to this are usually ecosystem specific and often annoying to use for someone…

The last-millennium solution to me-only installs is to put stuff in $HOME/bin, $HOME/lib, and $HOME/etc, and put those in the appropriate paths. Build the package with e.g. CMAKE_INSTALL_PREFIX=$HOME. At some point I switched to putting those dirs all in $HOME/opt for tidiness.

It's worked for me since workstations were shaped like pizza boxes.

I'm sure there are some things it can't do, but it goes a long way. When you're installing distributed binary packages you have less ability to control the baked-in install dirs, but if the package honors the conventional $(env) it can work.

Re: Show HN: Homebrew 6.0.0

#342
post #111

Earlier quoted context omitted.

> We'll lose support from you guys a year before Apple! If only Apple put a fraction of its resources towards maintaining something like homebrew (or paying the people who do), maybe the situation would be different.

MacPorts supports everything all the way back to 10.5/powerpc.

That's impressive, but I'd be reluctant to criticize one open source maintained effort for not having parity with another when it's all volunteer-driven. My point was that Apple is an insanely profitable company with resources that are effectively unlimited compared to what Homebrew has (and presumably likewise when compared to Macports), so the initial framing of "this will stop being supported before Apple" seemed pretty silly to me.

Re: Show HN: Homebrew 6.0.0

#344
A small note of amazement from Nix/Flox person here. Incredible to see this release and congrats! Mike, you're an allstar for so many years of contributions!

Re: Show HN: Homebrew 6.0.0

#345

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.

> We'll lose support from you guys a year before Apple! Homebrew will still work (increasingly poorly) on macOS Intel for a year after that, it just won’t be “supported” or tested in CI environments (where currently macOS Intel usually slows down the release of lots of software for all other platforms). That a volunteer run project with no employees is unable to come anywhere near the support levels of the world’s se…

That's a very reasonable answer thank you.

Re: Show HN: Homebrew 6.0.0

#346

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…

Hmm, `mise use -g docker-cli` works for me. `docker compose` is a bit trickier – it gets installed as `docker-cli-plugin-docker-compose`, but docker-cli doesn’t seem to pick it up. I’ve added a symlink as `docker-compose` for the time being. Also using brew for casks, and I think there’s a couple tools I couldn’t install with mise (e.g. pngpaste and zbar for scanning QR codes from screenshots).

There's the rename-exe option in mise.toml to rename the docker compose binary to `docker-compose`. I've used it on some machine, I think. Look it up in the docs, it doesn't take long to wire up.

Re: Show HN: Homebrew 6.0.0

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

Mise has two ways of running tools: the default one is ad-hoc PATH modifications, but there's also a shim folder you can add to PATH globally. If you mean the Claude desktop app or IDE plugin, the shim option is usually required, just edit the PATH the app is using (or the system-wide one).

Re: Show HN: Homebrew 6.0.0

#349

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…

That's kind of weird that you're using this announcement to steer people to another project. Or am I missing something..?

Yeah that brew is terrible

Re: Show HN: Homebrew 6.0.0

#350

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 like mise a lot, but only use it for project specific tool management, JDK versions, etc. I tried to use it for system wide things, but found it didn't work as well for me with things that I wanted to just be tools where I didn't care what specific version it was as long as it was more or less current, Helix, NeoVim, RipGrep, etc.

I use it for everything I can. Works very well
Post reply on HN