Kelp – simple replacement for homebrew on macOS | Hacker News Reader

Kelp – simple replacement for homebrew on macOS

github.com

87 pointsamai64 comments

Last week I had to download a dependency on Homebrew. It had been a while since I had downloaded anything as my personal device had been stable for a long time, so dependencies were out of date. Well, homebrew decided to upgrade EVERYTHING before it started the new download, all without my prompt. An hour later, I was met with a device that was full of issues, and it took me an entire week to fully get back to normal. Not saying I hate homebrew, but I welcome any competition in this space.

Add this to your shell profile:

  export HOMEBREW_NO_AUTO_UPDATE=1
  export HOMEBREW_NO_ANALYTICS=1

Why these aren't the defaults, I don't know.

Maybe also these, to limit other annoyances:

  export HOMEBREW_NO_EMOJI=1
  export HOMEBREW_NO_ENV_HINTS=1
  export HOMEBREW_NO_INSTALL_CLEANUP=1

Out of curiosty, why the last one? If you update a package, generally you don't need the old version, why would you keep it around? I can imagine this being useful in some edge cases, but as a global setting, I'm not so sure.

I got bitten by broken upgrades in the past, when you were still able to simply "brew switch" to the old version if it was there. In addition the cleanup time is annoying when upgrading a lot of packages, so I kept the setting.

There's an explanation somewhere as to why. It has to do with "not breaking" stuff relying on it. So I guess it only answers "why we won't fix it".

Anyway, I don't think this is enough. Or I guess it only works to stop the trigger during install? I have the NO_AUTO_UPDATE set up, and recently needed to update (or upgrade? who knows) a single package and it somehow ended up with Homebrew working for over two hours. I saw it installing python at least two times.

That's not a proper explanation IMO. The thing is - all these settings are introduced "quietly" as new defaults and you have to opt out. So one day you decide to upgrade a package, brew updates itself, and then starts doing all these things that weren't present before (and are most likely not needed at all). It's very annoying, and a dark pattern to say the least.

because the fundamental ethos of homebrew and a lot of “modern” tools is to prioritize the conservation of attention. Aka “don’t make me think“ which, ironically, appears to often be adopted, not only on behalf of users, but at a meta level, so things which might well deserve prompts are simply pre-configured.

some charity is due here, because this is the culture, and also because for any software tool of sufficient complexity, there is always more to think about than attention to give. But the culture could use more improvement and reflection here.

I feel you. I could write an essay about Homebrew, instead I'll list the other alternatives. There's pkgsrc[1], MacPorts[2], and Nix[3]. In my experience, none of these are as comprehensive, and each comes with its own quirks. Worth a try, might work for you.

[1]: https://www.pkgsrc.org/, https://pkgsrc.smartos.org/install-on-macos/

[2]: https://www.macports.org/

[3]: https://nixos.org/download/

It’s a bit surprising to hear nix described as “not as comprehensive”, considering they’ve basically built a whole OS around it, but I’m curious about your take on this specifically.

Mostly the prebuilt binary packages, "casks". Out of 13 casks I currently have installed, only 6 are in nixpkgs. Some are built for Linux (e.g. Ungoogled Chromium), but not for Mac.

I've also cherry-picked a couple non-cask packages that I would dearly miss: dark-notify, ddcctl, displayplacer, the kinda stuff you need to "fix" macOS.

I have found `mise` to be a pretty good way to install tooling https://github.com/cybernetics/mise-en-place

I've been using Jetify's Devbox instead of Homebrew for the last few months, with Mise for project specific installs. I've mostly found this to be much better than Homebrew, but Devbox has some flakiness. Working with Mise has been excellent though, and led me to finding `Ubi` [0] (it's a backend for Mise when needed) which seems to be doing roughly the same thing. Beyond this scratching your itch (which is always the best reason to make something), does it have any differentiators from Ubi?

[0] https://github.com/houseabsolute/ubi

Curious why you need to use mise on top of devbox, I thought they both filled the same niche? They both let you specify dependencies for a directory, and optionally install tools globally.

It's a good question, and to be honest, I occasionally get confused about what tools are installed with what tool manager (especially as there's also `uv tool` in the mix too).

Devbox for me hasn't clicked as a project-level tool manager, mostly because it doesn't really play nicely with the way our projects are set up causing a lot of shell issues for other team members. Mise has been trouble free on that front though, works perfectly for everyone on the team, and has some nice runner type functionality too (like `just` or `make`). If you've not tried Mise, I recommend giving it a go, it's really nice.

We recently switched to Mise, agreed it's been pain free. But in looking at options I was mulling over devbox so figured I'd ask.

I did notice that devbox seems to be able to generate a file for direnv, maybe that would help?

If you limit yourself to common programming languages and single-binary programs (e.g. ones written in Rust/Go) then I cannot recommend Mise enough to you. Absolute bliss compared to homebrew, asdf and other projects especially if you want multiple versions of tools in different projects.

https://mise.jdx.dev/

Thanks for this, mate! I’ve been adopting asdf for some time now, but you are 5 years ahead!

Nix (and nix-darwin for persistent config) already does the job for non-GUI apps better than anything else could (its catalog is unmatched), and homebrew (also available in nix-darwin) handles GUI apps.

Coming from nixos, I didn't want to use brew but I found nix-darwin to be poorly documented and supported.

Several upgrades wrecked havoc on my system, a lot of things didn't work as expected, I had to package a lot of stuff; eventually I just bit the bullet and started using homebrew

I sort of get what you're saying and I've had a few sporadic issues myself, once or twice I had to reinstall (although might have been my mishandling), but overall I can't see a better solution than this. Plus I can share the configs with Linux.

I doubt nix is ever going to enjoy popularity on the scale of Homebrew due to its differing model. People are too used to doing a simple “x install y” without any backing configuration or flakes or anything like that.

Personally speaking I might learn it at some point but for now nix's friction/overhead isn’t proportional to the occaisional inconvenience with traditional package managers.

I think Nix has a marketing issue as it goes so deep. But if you're going to consider it only as an alternative to homebrew, you don't have to know anything aside from different CLI invocations: `nix-shell -iA <package>` to install, and maybe a step up with `nix-shell -p <package> --run <cmd>` to run without installing. You don't have to use nix-darwin or managing configs and the Nix language at all.

That’s still more to remember than `x install y`, which might sound trivial but that’s the exact kind of friction that impedes adoption.

Maybe it would make sense for nix to add a mode that basically aliases that first command to `nix install <package>`.

That's essentially what Devbox does for you as a package manager, a hand wrapper around nix for using nix just for its package ecosystem.

Oh yeah, I knew about devbox but hadn't seen (perhaps it's new) that it can handle global packages: https://www.jetify.com/docs/devbox/devbox_global/

Yeah, I'm just addressing you specifically, you could switch easily and Nix has a much larger package selection (outside of GUI apps on macOS). And it immediately can do more via nix-shell -p, which can be also be used as shebang.

But yeah, Nix is much more than a homebrew replacement and that has its downsides.

Nix may have a larger selection, but I sampled a few of the projects I install from homebrew and...

1. Did't actually exist

2. Outdated version

3. Incorrect build

I'll keep the quality of Homebrew packages over the quantity in Nix

I'm curious of what the packages are because I only have ~10 packages that I use from homebrew, either very Mac-specific or that have better packaging (ffmpeg, mpv)

Not going to list them all, but...

@M4MBP ~ % brew list | wc -l

149

Some/many of those are likely to be dependencies. For example, it shows openssl@1.1 and openssl@3 on my machine

`brew leaves` will show manually installed packages.

Right, but I don't think that's the issue.

If the complaint is that other systems are less up-to-date than brew is, then the number of things installed is still the issue - whether they're dependencies or not.

Unless, of course, the other system manages dependencies differently, say it compiles in static versions of required libraries at build-time, or divides them up into fewer dependent packages.

They are all projects that distribute Go binaries on GitHub and have official homebrew taps

The 2/3 that are on nix are both out of date and created by some outside party.

I do not see a world where I provide nix stuff for my projects. There are already too many packages managers and I'm not spending my unpaid time to support all of them. GitHub and brew are my limit, def not learning nix just for this

I tried nix a few times in the past and it has too many issues on Mac (never got it working), also the learning curve is too steep, maybe I'll give it a try again.

An easy option nowadays is Determinate Nix https://docs.determinate.systems/determinate-nix/

So, an "easy" "better" option is:

- worse ux (nix commands are much more cumbersome and often make no sense compared to `brew install`)

- you have to use some third-party wrappers to make it work on Mac

- features incomplete and outdated packages (and is missing others apparently https://news.ycombinator.com/item?id=44034446)

... but it "does the job better than anything else could".

---

This is the issue I have with the whole nix discourse: it's hailed as this great magical tool. But when pressed for details it's always this: weird commands, configs, working or non-working wrappers etc.

This is just from my experience, I'm not part of any kind of Nix cult or anything, not that I'm aware of.

I don't know what you're talking about re: third party wrappers, this is just an option for a slightly easier and perhaps more robust install. And homebrew isn't free of issues at all.

So a "better than anything" still needs "a better more robust install" and you still use homebrew for "packages that are packaged better like ... the extremely popular and often installed ffmpeg"

;)

> And homebrew isn't free of issues at all.

No one advertises brew as "the best", "better than everything else" etc.

BTW, looked at Determinate Nix. It's a custom distribution and a custom daemon, and its own fork of documentation

I don't use Determinate Nix but I've heard it recommended. As I've said I've had 1 or 2 issues with my Nix install on Mac over several years.

Re: ffmpeg, it's just something do to with default codecs or something I don't remember, I'm not even sure I really needed it but I saw it on my packages list and since I use nix-darwin it doesn't matter that much where the package comes from. I have hundreds of packages from nixpkgs, many shared with Linux, and quite a few Mac specific ones.

Again, I'm not part of a Nix cult, I just genuinely have had an overall great experience with Nix and I find the criticism overblown. I guess since a subset of users are very enthusiastic and vocal about it it attracts this.

Before getting a new MacBook, I was using MacPorts since Homebrew had several problems, including what the GP mentioned. For over a year now, I have used home-manager with Nix. Nixpkgs has the "important" subset of GUI programs that I use. Major exception to this is OrbStack, but there is a homebrew-to-nix converter that I use to handle that.

I briefly experimented with nix-darwin, but concluded that it was overkill for my needs. Home Manager also has the benefit of not being Mac-specific (so plenty of questions and examples exist online).

Most importantly, I no longer have to mentally prepare myself when updating Mac OS. If I recall correctly, both MacPorts and Homebrew require the user to re-install all installed packages after a major version update, but this problem doesn't really exist on Nix. It's also nice being able to store flakes in a Git repository and effortlessly rollback changes or replicate a whole development environment across several machines.

I'm interested in how you use that homebrew-to-nix converter, if you have links to configs or can describe it briefly!

I agree that nix-darwin is a bit overkill, I mainly use it for the homebrew integration, but I think so is home-manager, I don't keep user app configs in Nix since they are never exhaustive and more effort than it's worth.

Still a macports user, however I used homebrew for a short period. What is the benefit here from homebrew? Compile speed?

It isn't very clear on that, but I think it is a way of automatically downloading binaries from Github releases. If so, that wouuld work well in some cases, and poorly in others

Part of the appeal of Homebrew (which is also a blessing and a curse from time to time) is the fact that packages are maintained, meaning people make conscious decisions when to pull in updated versions or stick with an older release, and have some logic behind all that mess.

There are always tradeoffs with any packaging system, no matter how transparent/simple.

Hombrew just pulls the latest versions of everything I have installed whenever I try and install one new unrelated thing. The defaults are kind of annoying in that:

" Unless $HOMEBREW_NO_INSTALLED_DEPENDENTS_CHECK is set, brew upgrade or brew reinstall will be run for outdated dependents and dependents with broken linkage, respectively.

       Unless $HOMEBREW_NO_INSTALL_CLEANUP is set, brew cleanup will then be
       run for the upgraded formulae or, every 30 days, for all formulae."

However I don't think even these flags are sufficient. I think to really ensure nonbreaking behavior you have to use a brew pin command on each and every formula you have installed on the system.

Really annoying defaults considering brew is a developer facing program not a consumer facing program where the tradeoff between security and functionality makes more sense.

This is why I still reach for conda whenever possible. I am at least prompted before 100 things are installed.

The defaults are the correct choice for a stable system unless you’re going to make full isolated installs for every package. The packages are built and tested together so holding back some updates is a recipe for inconsistent behaviour because everyone’s system will have different versions of everything based on when they installed packages. We stopped doing that for good reasons.

It’s been many years since I’ve had a problem caused by Homebrew’s design but if you like keeping things frozen like that, it sounds like you might be a better fit for Nix or working in containers where you aren’t fighting a distribution designed to stay consistently current across the entire system.

Yeah the happy medium I have found is to just see if the authors have submitted the package to anaconda and use that instead. Brew when that is no longer available. I will usually have one conda env per package or at the most per project.

It isn't just that things "work together" but in some cases authors change how their tools work between versions and I may have stuff installed that depends on these outdated paradigms. In other words, the stuff I have built is not sure to work together with updated brew packages. I have a few scripts for example where numpy complains how I call some function will no longer merely throw a warning but actually not work at all in future versions. I can either spend my free time to rewrite the script to do it how the numpy authors now want me to do it, or I can just not do that and live on the old numpy and not be any worse for wear.

You should really try `pixi` and `pixi global` - uses Conda packages but much faster, and great experience for installing packages globally.

https://pixi.sh

I’ve been using MacPorts for over 10 years now. As far as I know, version stubbing isn’t supported—you have to upgrade regardless. Another feature I find missing is the ability to sync installations across multiple systems. For example, if I install pkg1 on system1, I’d like it to automatically be available on system2 as well.

I think having venv like project installations would be nice as well. Let me write a Portfile for my current repo, use the system package cache if available, otherwise install locally. With clones it wouldn’t even require much extra space.

I've found bin[0] to be great (and simple) to manage binaries released via github, specifically those tools not already available via macports and ones for which I'm too lazy to write a portfile for. Seems like kelp is attempting to replace this combination with one tool.

[0]: https://github.com/marcosnils/bin

Shouldn't we all move to `mise-en-place` https://mise.jdx.dev/ as it is a kind of meta-package provider which works with a lot of those packaging systems?

I recently started poking through more of mise and it’s so nice. I don’t know if it covers homebrews gui installs, but everything cli I’m trying to install with mise these days

I personally use eget for this usecase. Might be worth a look: https://github.com/zyedidia/eget

Without knocking this tool, which I haven't tried, there seems to be something about the inability of a package manager to stay simple—MacPorts was the simple (or at least "it just works") replacement for Fink, Homebrew was the simple replacement for MacPorts, ... I don't know what came before Fink, because that's what was used when I first started using macOS. That was under Tiger, relatively early in the OS X days, so maybe Fink was actually the first?

We've been building `pixi` and more specifically "pixi global" as a replacement for homebrew, but based on Conda packages. It creates a single virtual environment per globally installed tool (deduplication works by hard-linking) and then links out the binaries from the isolated environments to a single place.

It's written in Rust and quite fast: https://pixi.sh

Packaging (non)story is interesting:

> What if the package I want is not on github releases?

Easy. Just add the http(s) link to the binary

ie:

kelp add -r https://releases.hashicorp.com/terraform/0.11.13/terraform_0... hashicorp/terraform

Seems like this space is really heating up the last few weeks. The rust based tool sps[0] is also looking to fill this niche, though perhaps being much closer to brew's system.

[0]https://github.com/alexykn/sps

the original homebrew creator made this new one too I think: https://github.com/pkgxdev

Kelp is several years old already

I already switched from zsh to fish; kelp would bring unbelievable synergy to my terminal

How do I know that the packages installed by this new manager are trustworthy?

What’s the cutesy naming scheme for this? Are you taking suggestions? If so you should call repository “coralbanks” and leaves

Reply on news.ycombinator.com