6 ms·

Kelp – simple replacement for homebrew on macOS

87 points by amai 1y ago

righthand 1y ago
Still a macports user, however I used homebrew for a short period. What is the benefit here from homebrew? Compile speed?
- steeleduncan 1y ago
  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
  - geerlingguy 1y ago
    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.
    - asdff 1y ago
      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.
      - acdha 1y ago
        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.
        deleted 1y ago
        [deleted]
        asdff 1y ago
        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.
      - droelf 1y ago
        You should really try `pixi` and `pixi global` - uses Conda packages but much faster, and great experience for installing packages globally. https://pixi.sh https://pixi.sh
- atmosx 1y ago
  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.
  - jonhohle 1y ago
    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.
drcongo 1y ago
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 https://github.com/houseabsolute/ubi
- c-hendricks 1y ago
  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.
  - drcongo 1y ago
    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.
    - c-hendricks 1y ago
      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?
internet2000 1y ago
What’s the cutesy naming scheme for this? Are you taking suggestions? If so you should call repository “coralbanks” and leaves
oulipo 1y ago
Shouldn't we all move to `mise-en-place` https://mise.jdx.dev/ https://mise.jdx.dev/ as it is a kind of meta-package provider which works with a lot of those packaging systems?
- clayhacks 1y ago
  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
chin7an 1y ago
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 https://github.com/marcosnils/bin
lambdaba 1y ago
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.
- jokethrowaway 1y ago
  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
  - lambdaba 1y ago
    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.
  - deleted 1y ago
    [deleted]
- cosmic_cheese 1y ago
  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.
  - lambdaba 1y ago
    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.
felipellrocha 1y ago
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.
- Etheryte 1y ago
  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.
  - nuxi 1y ago
    Maybe also these, to limit other annoyances: export HOMEBREW_NO_EMOJI=1 export HOMEBREW_NO_ENV_HINTS=1 export HOMEBREW_NO_INSTALL_CLEANUP=1
    - Etheryte 1y ago
      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.
      - nuxi 1y ago
        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.
  - wwweston 1y ago
    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.
pomdtr 1y ago
I personally use eget for this usecase. Might be worth a look: https://github.com/zyedidia/eget https://github.com/zyedidia/eget
mx-bojangles 1y ago
How do I know that the packages installed by this new manager are trustworthy?
sfpityparty 1y ago
[flagged]
droelf 1y ago
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 https://pixi.sh
natemcintosh 1y ago
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 https://github.com/alexykn/sps
- nikisweeting 1y ago
  the original homebrew creator made this new one too I think: https://github.com/pkgxdev https://github.com/pkgxdev
- msephton 1y ago
  Kelp is several years old already
e12e 1y ago
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.11.13_darwin_amd64.zip https://releases.hashicorp.com/terraform/0.11.13/terraform_0... hashicorp/terraform
JadeNB 1y ago
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?
disintegrator 1y ago
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/ https://mise.jdx.dev/
- suralind 1y ago
  Thanks for this, mate! I’ve been adopting asdf for some time now, but you are 5 years ahead!
Shalomboy 1y ago
I already switched from zsh to fish; kelp would bring unbelievable synergy to my terminal

87 points by amai 1y ago

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

steeleduncan 1y ago
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
- geerlingguy 1y ago
  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.
  - asdff 1y ago
    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.
    - acdha 1y ago
      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.
      - deleted 1y ago
        [deleted]
      - asdff 1y ago
        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.
    - droelf 1y ago
      You should really try `pixi` and `pixi global` - uses Conda packages but much faster, and great experience for installing packages globally. https://pixi.sh https://pixi.sh
atmosx 1y ago
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.
- jonhohle 1y ago
  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.

drcongo 1y ago

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 https://github.com/houseabsolute/ubi

c-hendricks 1y ago
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.
- drcongo 1y ago
  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.
  - c-hendricks 1y ago
    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?

internet2000 1y ago

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

oulipo 1y ago

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

clayhacks 1y ago
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

chin7an 1y ago

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 https://github.com/marcosnils/bin

lambdaba 1y ago

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.

jokethrowaway 1y ago
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
- lambdaba 1y ago
  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.
- deleted 1y ago
  [deleted]
cosmic_cheese 1y ago
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.
- lambdaba 1y ago
  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.

felipellrocha 1y ago

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.

Etheryte 1y ago
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.
- nuxi 1y ago
  Maybe also these, to limit other annoyances: export HOMEBREW_NO_EMOJI=1 export HOMEBREW_NO_ENV_HINTS=1 export HOMEBREW_NO_INSTALL_CLEANUP=1
  - Etheryte 1y ago
    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.
    - nuxi 1y ago
      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.
- wwweston 1y ago
  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.

pomdtr 1y ago

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

mx-bojangles 1y ago

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

sfpityparty 1y ago

[flagged]

droelf 1y ago

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 https://pixi.sh

natemcintosh 1y ago

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 https://github.com/alexykn/sps

nikisweeting 1y ago
the original homebrew creator made this new one too I think: https://github.com/pkgxdev https://github.com/pkgxdev
msephton 1y ago
Kelp is several years old already

e12e 1y ago

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.11.13_darwin_amd64.zip https://releases.hashicorp.com/terraform/0.11.13/terraform_0... hashicorp/terraform

JadeNB 1y ago

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?

disintegrator 1y ago

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/ https://mise.jdx.dev/

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

Shalomboy 1y ago

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