28 ms·

Nanobrew: The fastest macOS package manager compatible with brew

225 points by syrusakbary 6mo ago

an0malous 6mo ago
Does it reinstall postgres for every package install?
- mitchitized 6mo ago
  (report card for an0malous): "Does not play nice with other students."
  - an0malous 6mo ago
    It's true :')
- ericcholis 6mo ago
  HOMEBREW_NO_AUTO_UPDATE=1 will disable this (annoying) behavior. Set it in your bashrc or zshrc.
  - deleted 6mo ago
    [deleted]
chuckadams 6mo ago
This might be a good thing for homebrew to adopt for the download/install process, but if it doesn't include a ruby interpreter, I have a hard time seeing how it's going to be compatible with anything but searching and installing bottles. I install most of my packages from a Brewfile, which itself is Ruby code.
- alwillis 6mo ago
  > I install most of my packages from a Brewfile, which itself is Ruby code. Same. Whatever happens, the new version should support Brewfile.
mikemcquaid 6mo ago
If it doesn’t ever execute Ruby: it cannot be compatible with Homebrew. “Compatible” is doing a bit of work here when it also means “implicitly relies on Homebrew’s CDN, CI, packaging infrastructure and maintainers who keep all this running”. There’s a new vibe coded Homebrew frontend with partial compatibility and improved speed every few weeks. Homebrew is working on an official Rust frontend that will actually have full compatibility. Hopefully this will help share effort across the wider ecosystem.
- anbotero 6mo ago
  Wait a minute, Homebrew is slow? I thought most of the time it takes for me is downloading and installing. I haven't noticed slowdowns anywhere else, even for the ones mentioned.
- adityamwagh 6mo ago
  In it's current form, homebrew is amazing. It's not that slow and recent updates have made it really good to use. May I know the reasons for a Rust rewrite?
- pxc 6mo ago
  It is really coll that Homebrew provides a comprehensive enough JSON API to let people build on Homebrew in useful ways without directly running Ruby, despite everything being built in a Ruby DSL. That really does seem like a "best of both worlds" deal, and it's cool that alternative clients can take advantage of that. I didn't know about the pending, official Rust frontend! That's very interesting.
  - SOLAR_FIELDS 6mo ago
    Wow they are finally getting away from Ruby? Awesome. The speed will be a nice boon
    - petcat 6mo ago
      Yeah I don't know why people are saying that speed doesn't matter. I use Homebrew and it is slow. It's like yum vs apt in the Linux world. APT (C++) is fast and yum (Python) was slow. Both work fine, but yum would just add a few seconds, or a minute, of little frustrations multiple times a day. It adds up. They finally fixed it with dnf (C++) and now yum is deprecated. Glad to hear a Rust rewrite is coming to Homebrew soon.
drob518 6mo ago
This feels like a solution looking for a problem. I have a couple hundred brew packages on my system and I’ve never sat there thinking “If this was only 2 seconds faster…” while doing an update. I’m sure the Homebrew folks could mine this for a few ideas of how to further optimize brew, but I don’t think I’ll be adopting it anytime soon. Compatibility is more important than speed in this case.
- bobbylarrybobby 6mo ago
  I have definitely wished that Homebrew would not wait for all packages to be downloaded before pouring them. It's nice that downloads happen in parallel (didn't always used to be the case iirc), but it feels like the pouring could also be done in the same parallel workflow.
- pxc 6mo ago
  If you use the Homebrew module for Nix-Darwin, running `brew` against the generated brewfile becomes the slowest part of a `darwin-rebuild switch` by far. In the fast cases, it turns something that could take 1 second into something that takes 10, which is definitely annoying when running that command is part of your process for configuration changes even when you don't update anything. Homebrew no-ops against an unchanging Brewfile are really slow.
- dilap 6mo ago
  Horses for courses, but I've stopped using brew 'cuz it's too slow, so this might bring me back! Edit: no, it won't...
  - drob518 6mo ago
    Agreed on horses for courses. Different people have different tolerances. And yea, all things being equal, faster is better, but they are almost never equal. If you don’t mind me asking, what does “too slow” mean for you in this context? Do you have a particularly complex setup? And what do you use now as an alternative and how has that impacted the update speed?
    - 6mo ago
pxc 6mo ago
I've been looking for something like this, especially to use only with casks now that Homebrew has removed support for not adding the quarantine bit. Looking forward to giving it a try!
deleted 6mo ago
[deleted]
kassadin 6mo ago
Do you choose compatibility or speed? nb info --cask codex-app nb: formula '--cask' not found nb: formula 'codex-app' not found
luizfelberti 6mo ago
It might be good to explain how this differs from zerobrew [0], which is trying to accomplish the same thing [0] https://github.com/lucasgelfond/zerobrew https://github.com/lucasgelfond/zerobrew
- zieka 6mo ago
  I also have a solution mostly for myself but others are welcomed to it: https://zieka.github.io/bru/ https://zieka.github.io/bru/ Outlined some differences here between the various projects; might be useful: https://github.com/zieka/bru?tab=readme-ov-file#how-bru-compares https://github.com/zieka/bru?tab=readme-ov-file#how-bru-comp...
- tomComb 6mo ago
  And zerobrew, like the original Homebrew, is compatible with Linux. It appears that Nanobrew is not. I care about the light-weight efficiency of these new native code variants much more when I want to use brew on some little Linux container or VM or CI, than I do for my macOS development machine.
- Alifatisk 6mo ago
  Zerobrew looks mature, I'll check it out. Btw, I noted this: > Zerobrew is experimental. We recommend running it alongside Homebrew rather than as a replacement, and do not recommend purging homebrew and replacing it with zerobrew unless you are absolutely sure about the implications of doing so. So I guess its fine to run this alongside Homebrew and they don't conflict.
- phist_mcgee 6mo ago
  >Install zerobrew via brew as per the official instructions. >Immediately get an error saying the install path is too long and needs to be fixed as /opt/zerobrew/prefix is too many bytes. Yeah gonna need some work.
alsetmusic 6mo ago
I'm not a Python dev, but I appreciate the motivation uv has inspired across other package managers. I tried another brew replacement called zerobrew last month. It installed packages to a different directory from homebrew, so I didn't actually test drive after seeing that. Regardless, I look forward to the competition pushing mainstream tools to improve their performance.
ryandrake 6mo ago
What would be great is a Homebrew-compatible system that doesn't cut off support for older machines. I have a 3.8 GHz Quad core i5 iMac that still crushes, yet Homebrew has determined that I'm just too old and icky[1] to work with anymore. I had to move over to MacPorts, which is surprisingly nice, but I still miss brew. Yea, I know. It's open source. They can do what they want. Still sucks. 1: https://docs.brew.sh/Support-Tiers https://docs.brew.sh/Support-Tiers
- happyopossum 6mo ago
  To be fair, Apple stopped providing security fixes for Mojave ~4+ years ago, and there have been 7 or 8 new os releases since then… I don’t think it’s reasonable to expect an open source project to support everything
  - gabagool 6mo ago
    I agree in principle but Homebrew only supports the latest 3 versions of macOS. Right now Ventura 13 which came out in October 2022 is unsupported.
    - dewey 6mo ago
      I still think that's entirely fair for a power user tool like homebrew. With the upgrade rates of macOS that probably means that's 98% of the users would be covered. Expecting an open source project to accept bug requests from a bigger variety of versions that then would need test devices on these versions to replicate issues sounds unrealistic. Bigger companies, or Apple itself I would hold to much higher standards when it comes to that.
      - ksherlock 6mo ago
        brew used to say, more or less, "This OS is old and unsupported. Don't submit bug reports. If you have problems, too bad. If you submit a PR to fix something, we might merge it". Fair enough, right? Now it just says, "Go fuck yourself, grandpa."
tantalor 6mo ago
And why does speed matter in this case?
manlymuppet 6mo ago
If we get the Bun-ification of every package manager and language ecosystem that would be an awesome thing. This is a great trend.
maxloh 6mo ago
How does this work? AFAIK Homebrew formulae are written in Ruby [0]. Do they use some kind of Ruby parser to parse formulae? [0]: https://github.com/Homebrew/homebrew-core/blob/26-tahoe/Formula/f/ffmpeg.rb https://github.com/Homebrew/homebrew-core/blob/26-tahoe/Form...
- fny 6mo ago
  It uses the Homebrew API and uses its own dependency resolver and linker to pull Homebrew's precompiled packages.
Onavo 6mo ago
The current version of brew has a flaw where the installer can't install isolated dependency trees in a sterile manner. If you have packages A, B, C, and D that all have updates, and assuming A,B,C depend on each other and come out to a total of say 1MB, and D is 1000MB, brew works in a MapReduce manner where it will attempt to finish downloading everything in parallel (even though the real bottleneck is D) before doing any installation. Since the first 3 has no dependency on D, a better way would be to install them in parallel while D is still downloading.
marksully 6mo ago
what happens if I test this tool by installing some packages and then remove (the tool)? will I still be able to use Homebrew to manage these new packages?
12_throw_away 6mo ago
So, A) to what extent is this vibe coded? And B) what is "trilok.ai" where you download it from?
peytongreen_dev 6mo ago
[flagged]
themadsens 6mo ago
I naively assumed it would work on the already installed homebrew packages. No such luck. After installing, 'nb list' and thus eg. 'nb outdated' will yield the empty list! I have absolutely no use for a competing homebrew installation that is mostly compatible ..
hsaliak 6mo ago
This is most certainly vibed with a few optimization focused prompts. Yes - performance is a feature, but so is lack of risk.
MoonWalk 6mo ago
Inaccessible: net::ERR_CERT_AUTHORITY_INVALID
tzs 6mo ago
OT: speaking of Homebrew, I made an incorrect assumption about it that eventually led to some problems. It was me being stupid, but I bet others have made the same mistake but not yet hit problems. Hence this comment. My mistake was when I upgraded from my 2017 iMac (Intel processor) to an Apple silicon Mac at the start of 2024 and migrated via Time Machine I did not do anything extra specifically for Homebrew. I just assumed that as things got updated via the normal periodic Homebrew updates I run it would start grabbing the Apple silicon binaries for binary things it installed. It turn out that is wrong. They made Apple silicon Homebrew kind of independent of Intel Homebrew. Intel Homebrew uses /usr/local and Apple silicon Homebrew uses /opt/homebrew. This allows having both native and Intel Homebrew installed at the same time if you need both. The correct way to migrate from an Intel Mac to an Apple silicon Mac is to install Apple silicon Homebrew on the new Mac, and then install all the packages you want. Intel Homebrew works fine on Apple silicon Macs so you can use the Intel Homebrew that migrated via Time Machine to make the package list to use with Apple silicon Homebrew (or you can make it on the old Mac). I only noticed this because I was trying to build something from source using some libraries that were installed via Homebrew and running into problems. An LLM was helping figure this out and it was telling me I might have to manually symlink those libraries from where they were in /opt/homebrew to where the build process for the thing I was building expected to find them and I didn't have a /opt/homebrew. The libraries were somewhere in /usr/local. I then noticed those libraries were not for Apple silicon, checked other things installed view Homebrew and saw nothing was for Apple silicon, and realized I had the wrong Homebrew.
ryguz 6mo ago
[dead]
hirvi74 6mo ago
Why does the speed of a package manager matter? I'm being sincere too. I have used countless package managers, and speed is not an attribute of any of them that I have noticed.
coldtea 6mo ago
Tried to install a package with it, it failed. Tried the same package with brew. Worked like a charm. Uninstalled nanobrew.
denkmoon 6mo ago
Brew is a leaky piece of crap. nix 4 lyf. Seriously, I used to hate any time I needed to install something with brew not knowing if it was going to break everything else, since using nixpkgs for my macos dev requirements it's been so much nicer.
sanderwebs 6mo ago
I've found brew so painful that I switched to nix. Nix unfortunately is painful in its own way. However, I recently discovered devbox which is a wrapper around nix. It works really well as a package manager. Just run "devbox global add <package>"
- commandersaki 6mo ago
  This thread invigorated my interest in Nix to manage my Mac environment. I already have a Brewfile in my dotfiles stored in git, but wanted a way to setup all the little things on my Mac like trackpad settings, dock settings, file associations, etc. nix-darwin is the obvious solution. Gave the task to ChatGPT and it came back saying it's a good way to get started, but then offered a middle-ground of an idempotent script to set things up. So I investigated the latter, and after a couple of minutes I now have a setupmac() function in my .bash_profile (yeah I use bash) which mostly consists of a bunch of 'defaults' commands and a few other things, and now continue with brew for managing software and setupmac() to setup everything else, and of course manually manage my dotfiles for ghostty/nvim. I wish I had this earlier, because I just set myself up on 3 different Macs in the last week or so. I'm also glad I don't need to learn a new language and tooling for something pretty simple. Everything is a bit disjointed and not as automated as a proper nix setup and doesn't have that fidelity that nix has, but it's straight-forward, compact in that it sits in my brain easily, and easy to execute.
bibimsz 6mo ago
is this going to be like litellm?
orefalo 6mo ago
well nanobrew is not on brew!
NamlchakKhandro 6mo ago
No one should be using brew. It's terrible

225 points by syrusakbary 6mo ago

an0malous 6mo ago

Does it reinstall postgres for every package install?

mitchitized 6mo ago
(report card for an0malous): "Does not play nice with other students."
- an0malous 6mo ago
  It's true :')
ericcholis 6mo ago
HOMEBREW_NO_AUTO_UPDATE=1 will disable this (annoying) behavior. Set it in your bashrc or zshrc.
- deleted 6mo ago
  [deleted]

chuckadams 6mo ago

This might be a good thing for homebrew to adopt for the download/install process, but if it doesn't include a ruby interpreter, I have a hard time seeing how it's going to be compatible with anything but searching and installing bottles. I install most of my packages from a Brewfile, which itself is Ruby code.

alwillis 6mo ago
> I install most of my packages from a Brewfile, which itself is Ruby code. Same. Whatever happens, the new version should support Brewfile.

mikemcquaid 6mo ago

If it doesn’t ever execute Ruby: it cannot be compatible with Homebrew. “Compatible” is doing a bit of work here when it also means “implicitly relies on Homebrew’s CDN, CI, packaging infrastructure and maintainers who keep all this running”. There’s a new vibe coded Homebrew frontend with partial compatibility and improved speed every few weeks. Homebrew is working on an official Rust frontend that will actually have full compatibility. Hopefully this will help share effort across the wider ecosystem.

anbotero 6mo ago
Wait a minute, Homebrew is slow? I thought most of the time it takes for me is downloading and installing. I haven't noticed slowdowns anywhere else, even for the ones mentioned.
adityamwagh 6mo ago
In it's current form, homebrew is amazing. It's not that slow and recent updates have made it really good to use. May I know the reasons for a Rust rewrite?
pxc 6mo ago
It is really coll that Homebrew provides a comprehensive enough JSON API to let people build on Homebrew in useful ways without directly running Ruby, despite everything being built in a Ruby DSL. That really does seem like a "best of both worlds" deal, and it's cool that alternative clients can take advantage of that. I didn't know about the pending, official Rust frontend! That's very interesting.
- SOLAR_FIELDS 6mo ago
  Wow they are finally getting away from Ruby? Awesome. The speed will be a nice boon
  - petcat 6mo ago
    Yeah I don't know why people are saying that speed doesn't matter. I use Homebrew and it is slow. It's like yum vs apt in the Linux world. APT (C++) is fast and yum (Python) was slow. Both work fine, but yum would just add a few seconds, or a minute, of little frustrations multiple times a day. It adds up. They finally fixed it with dnf (C++) and now yum is deprecated. Glad to hear a Rust rewrite is coming to Homebrew soon.

drob518 6mo ago

This feels like a solution looking for a problem. I have a couple hundred brew packages on my system and I’ve never sat there thinking “If this was only 2 seconds faster…” while doing an update. I’m sure the Homebrew folks could mine this for a few ideas of how to further optimize brew, but I don’t think I’ll be adopting it anytime soon. Compatibility is more important than speed in this case.

bobbylarrybobby 6mo ago
I have definitely wished that Homebrew would not wait for all packages to be downloaded before pouring them. It's nice that downloads happen in parallel (didn't always used to be the case iirc), but it feels like the pouring could also be done in the same parallel workflow.
pxc 6mo ago
If you use the Homebrew module for Nix-Darwin, running `brew` against the generated brewfile becomes the slowest part of a `darwin-rebuild switch` by far. In the fast cases, it turns something that could take 1 second into something that takes 10, which is definitely annoying when running that command is part of your process for configuration changes even when you don't update anything. Homebrew no-ops against an unchanging Brewfile are really slow.
dilap 6mo ago
Horses for courses, but I've stopped using brew 'cuz it's too slow, so this might bring me back! Edit: no, it won't...
- drob518 6mo ago
  Agreed on horses for courses. Different people have different tolerances. And yea, all things being equal, faster is better, but they are almost never equal. If you don’t mind me asking, what does “too slow” mean for you in this context? Do you have a particularly complex setup? And what do you use now as an alternative and how has that impacted the update speed?
  - 6mo ago

pxc 6mo ago

I've been looking for something like this, especially to use only with casks now that Homebrew has removed support for not adding the quarantine bit. Looking forward to giving it a try!

deleted 6mo ago

[deleted]

kassadin 6mo ago

Do you choose compatibility or speed? nb info --cask codex-app nb: formula '--cask' not found nb: formula 'codex-app' not found

luizfelberti 6mo ago

It might be good to explain how this differs from zerobrew [0], which is trying to accomplish the same thing [0] https://github.com/lucasgelfond/zerobrew https://github.com/lucasgelfond/zerobrew

zieka 6mo ago
I also have a solution mostly for myself but others are welcomed to it: https://zieka.github.io/bru/ https://zieka.github.io/bru/ Outlined some differences here between the various projects; might be useful: https://github.com/zieka/bru?tab=readme-ov-file#how-bru-compares https://github.com/zieka/bru?tab=readme-ov-file#how-bru-comp...
tomComb 6mo ago
And zerobrew, like the original Homebrew, is compatible with Linux. It appears that Nanobrew is not. I care about the light-weight efficiency of these new native code variants much more when I want to use brew on some little Linux container or VM or CI, than I do for my macOS development machine.
Alifatisk 6mo ago
Zerobrew looks mature, I'll check it out. Btw, I noted this: > Zerobrew is experimental. We recommend running it alongside Homebrew rather than as a replacement, and do not recommend purging homebrew and replacing it with zerobrew unless you are absolutely sure about the implications of doing so. So I guess its fine to run this alongside Homebrew and they don't conflict.
phist_mcgee 6mo ago
>Install zerobrew via brew as per the official instructions. >Immediately get an error saying the install path is too long and needs to be fixed as /opt/zerobrew/prefix is too many bytes. Yeah gonna need some work.

alsetmusic 6mo ago

I'm not a Python dev, but I appreciate the motivation uv has inspired across other package managers. I tried another brew replacement called zerobrew last month. It installed packages to a different directory from homebrew, so I didn't actually test drive after seeing that. Regardless, I look forward to the competition pushing mainstream tools to improve their performance.

ryandrake 6mo ago

What would be great is a Homebrew-compatible system that doesn't cut off support for older machines. I have a 3.8 GHz Quad core i5 iMac that still crushes, yet Homebrew has determined that I'm just too old and icky[1] to work with anymore. I had to move over to MacPorts, which is surprisingly nice, but I still miss brew. Yea, I know. It's open source. They can do what they want. Still sucks. 1: https://docs.brew.sh/Support-Tiers https://docs.brew.sh/Support-Tiers

happyopossum 6mo ago
To be fair, Apple stopped providing security fixes for Mojave ~4+ years ago, and there have been 7 or 8 new os releases since then… I don’t think it’s reasonable to expect an open source project to support everything
- gabagool 6mo ago
  I agree in principle but Homebrew only supports the latest 3 versions of macOS. Right now Ventura 13 which came out in October 2022 is unsupported.
  - dewey 6mo ago
    I still think that's entirely fair for a power user tool like homebrew. With the upgrade rates of macOS that probably means that's 98% of the users would be covered. Expecting an open source project to accept bug requests from a bigger variety of versions that then would need test devices on these versions to replicate issues sounds unrealistic. Bigger companies, or Apple itself I would hold to much higher standards when it comes to that.
    - ksherlock 6mo ago
      brew used to say, more or less, "This OS is old and unsupported. Don't submit bug reports. If you have problems, too bad. If you submit a PR to fix something, we might merge it". Fair enough, right? Now it just says, "Go fuck yourself, grandpa."

tantalor 6mo ago

And why does speed matter in this case?

manlymuppet 6mo ago

If we get the Bun-ification of every package manager and language ecosystem that would be an awesome thing. This is a great trend.

maxloh 6mo ago

How does this work? AFAIK Homebrew formulae are written in Ruby [0]. Do they use some kind of Ruby parser to parse formulae? [0]: https://github.com/Homebrew/homebrew-core/blob/26-tahoe/Formula/f/ffmpeg.rb https://github.com/Homebrew/homebrew-core/blob/26-tahoe/Form...

fny 6mo ago
It uses the Homebrew API and uses its own dependency resolver and linker to pull Homebrew's precompiled packages.

Onavo 6mo ago

The current version of brew has a flaw where the installer can't install isolated dependency trees in a sterile manner. If you have packages A, B, C, and D that all have updates, and assuming A,B,C depend on each other and come out to a total of say 1MB, and D is 1000MB, brew works in a MapReduce manner where it will attempt to finish downloading everything in parallel (even though the real bottleneck is D) before doing any installation. Since the first 3 has no dependency on D, a better way would be to install them in parallel while D is still downloading.

marksully 6mo ago

what happens if I test this tool by installing some packages and then remove (the tool)? will I still be able to use Homebrew to manage these new packages?

12_throw_away 6mo ago

So, A) to what extent is this vibe coded? And B) what is "trilok.ai" where you download it from?

peytongreen_dev 6mo ago

[flagged]

themadsens 6mo ago

I naively assumed it would work on the already installed homebrew packages. No such luck. After installing, 'nb list' and thus eg. 'nb outdated' will yield the empty list! I have absolutely no use for a competing homebrew installation that is mostly compatible ..

hsaliak 6mo ago

This is most certainly vibed with a few optimization focused prompts. Yes - performance is a feature, but so is lack of risk.

MoonWalk 6mo ago

Inaccessible: net::ERR_CERT_AUTHORITY_INVALID

tzs 6mo ago

OT: speaking of Homebrew, I made an incorrect assumption about it that eventually led to some problems. It was me being stupid, but I bet others have made the same mistake but not yet hit problems. Hence this comment. My mistake was when I upgraded from my 2017 iMac (Intel processor) to an Apple silicon Mac at the start of 2024 and migrated via Time Machine I did not do anything extra specifically for Homebrew. I just assumed that as things got updated via the normal periodic Homebrew updates I run it would start grabbing the Apple silicon binaries for binary things it installed. It turn out that is wrong. They made Apple silicon Homebrew kind of independent of Intel Homebrew. Intel Homebrew uses /usr/local and Apple silicon Homebrew uses /opt/homebrew. This allows having both native and Intel Homebrew installed at the same time if you need both. The correct way to migrate from an Intel Mac to an Apple silicon Mac is to install Apple silicon Homebrew on the new Mac, and then install all the packages you want. Intel Homebrew works fine on Apple silicon Macs so you can use the Intel Homebrew that migrated via Time Machine to make the package list to use with Apple silicon Homebrew (or you can make it on the old Mac). I only noticed this because I was trying to build something from source using some libraries that were installed via Homebrew and running into problems. An LLM was helping figure this out and it was telling me I might have to manually symlink those libraries from where they were in /opt/homebrew to where the build process for the thing I was building expected to find them and I didn't have a /opt/homebrew. The libraries were somewhere in /usr/local. I then noticed those libraries were not for Apple silicon, checked other things installed view Homebrew and saw nothing was for Apple silicon, and realized I had the wrong Homebrew.

ryguz 6mo ago

[dead]

hirvi74 6mo ago

Why does the speed of a package manager matter? I'm being sincere too. I have used countless package managers, and speed is not an attribute of any of them that I have noticed.

coldtea 6mo ago

Tried to install a package with it, it failed. Tried the same package with brew. Worked like a charm. Uninstalled nanobrew.

denkmoon 6mo ago

Brew is a leaky piece of crap. nix 4 lyf. Seriously, I used to hate any time I needed to install something with brew not knowing if it was going to break everything else, since using nixpkgs for my macos dev requirements it's been so much nicer.

sanderwebs 6mo ago

I've found brew so painful that I switched to nix. Nix unfortunately is painful in its own way. However, I recently discovered devbox which is a wrapper around nix. It works really well as a package manager. Just run "devbox global add <package>"

commandersaki 6mo ago
This thread invigorated my interest in Nix to manage my Mac environment. I already have a Brewfile in my dotfiles stored in git, but wanted a way to setup all the little things on my Mac like trackpad settings, dock settings, file associations, etc. nix-darwin is the obvious solution. Gave the task to ChatGPT and it came back saying it's a good way to get started, but then offered a middle-ground of an idempotent script to set things up. So I investigated the latter, and after a couple of minutes I now have a setupmac() function in my .bash_profile (yeah I use bash) which mostly consists of a bunch of 'defaults' commands and a few other things, and now continue with brew for managing software and setupmac() to setup everything else, and of course manually manage my dotfiles for ghostty/nvim. I wish I had this earlier, because I just set myself up on 3 different Macs in the last week or so. I'm also glad I don't need to learn a new language and tooling for something pretty simple. Everything is a bit disjointed and not as automated as a proper nix setup and doesn't have that fidelity that nix has, but it's straight-forward, compact in that it sits in my brain easily, and easy to execute.

bibimsz 6mo ago

is this going to be like litellm?

orefalo 6mo ago

well nanobrew is not on brew!

NamlchakKhandro 6mo ago

No one should be using brew. It's terrible