Nanobrew: The fastest macOS package manager compatible with brew
108 points by syrusakbary 6 hours ago | 65 comments
  • an0malous 4 hours ago |
    Does it reinstall postgres for every package install?
    • mitchitized 4 hours ago |
      (report card for an0malous): "Does not play nice with other students."
      • an0malous 4 hours ago |
        It's true :')
    • ericcholis 4 hours ago |
      HOMEBREW_NO_AUTO_UPDATE=1 will disable this (annoying) behavior. Set it in your bashrc or zshrc.
  • chuckadams 4 hours 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 3 minutes 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 4 hours 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.

    • pxc 3 hours 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 3 hours ago |
        Wow they are finally getting away from Ruby? Awesome. The speed will be a nice boon
        • petcat 2 hours 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.

          • novok 21 minutes ago |
            Ruby doesn't have to be the slow part, bazel uses starlark which is mostly python and it's very fast.
    • atonse 3 hours ago |
      Heyyyy, who are you to tell us what is and isn't compatible with homebrew?

      (Just kidding, thank you for creating homebrew and your continued work on it!)

    • tfrancisl 2 hours ago |
      I appreciate the push for an official rust frontend. I've personally been migrating (slowly) to using nix to manage my Mac's software, but there are a ton of limitations which lead me to rely on homebrew anyway. The speed ups will be appreciated.
    • boobsbr 2 hours ago |
      Please, don't remove bottles and casks that are blocked by Gatekeeper. :˜(
    • halapro 2 hours ago |
      Makes no sense, the wording suggests it can use Homebrew's backend, not that it's a complete alternative to Homebrew. Nobody is confused about that.
      • nozzlegear 2 hours ago |
        I mean, I'm confused about it. The nanobrew homepage says this:

        > nanobrew

        > The fastest macOS package manager. Written in Zig.

        > 3.5ms warm install time

        > 7,000x faster than Homebrew · faster than echo

        It presents itself as an alternative to Homebrew.

        • halapro 2 hours ago |
          There are many such examples for npm as well: many "compatible" managers, one registry.
          • nozzlegear an hour ago |
            Sorry, examples of what? Package managers that present themselves as replacements for other package managers? Or package managers that aren't compatible with the registry they're supposed to be compatible with? Your use of scare quotes is confusing.
            • 0x457 24 minutes ago |
              pnmp, npm, yard all have different lockfiles, all use the same registry format (and the same registry itself), all try to stay compatible in other ways.

              You won't be having situation where one uses yarn and someone uses pnpm on the same project tho.

    • orf 2 hours ago |
    • runjake an hour ago |
      Context for those unaware: the commenter, mikemcquaid, is the project lead for Homebrew.
      • Xunjin 44 minutes ago |
        Thank you, his arguments totally makes sense, only the part that makes me icky is:

        > There’s a new vibe coded Homebrew frontend with partial compatibility and improved speed every few weeks.

        People are free and probably do this because it is slow. Alternatives often are not a bad thing.

        • runjake 22 minutes ago |
          Point noted! I took it as a tongue-in-cheek phrasing of "agentically coded". Hopefully, that's right.
        • alwillis 11 minutes ago |
          Since I enabled HOMEBREW_DOWNLOAD_CONCURRENCY, downloads have improved for me to the point where download speed is no longer an issue.
  • drob518 4 hours 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.
    • pxc 4 hours 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 4 hours 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 3 hours 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?
    • swiftcoder 3 hours ago |
      > I’ve never sat there thinking “If this was only 2 seconds faster…” while doing an update

      I definitely have thought something along those lines (mostly when I go to install a small tool, and get hit with 20 minutes of auto-updates first).

      Pretty sure I also will not be adopting this particular solution, however

      • bombcar 3 hours ago |
        I've never thought "only 2 seconds faster" - I've certainly thought "why is this taking half the time it takes Gentoo to recompile an entire server".
      • SOLAR_FIELDS 3 hours ago |
        FWIW this seems to have improved in recent years. Back in the dark times of non parallelized downloads I would purposefully wait to end of day and fire the thing off before leaving
      • joshstrange 3 hours ago |
        But you can turn that behavior off, IIRC it tells you the environment variable to set if you don’t want it to do that every time it runs.

        I agree it’s annoying, but I haven’t turned it off because it’s only annoying because I’m not keeping my computer (brew packages) up-to-date normally (aka, it’s my own fault).

        • slackfan 3 hours ago |
          Terrible default behavior is a great reason to abandon a software package.
        • swiftcoder 2 hours ago |
          I'd be much happier if it were on a background job, than arbitrarily running when I invoke a command
    • mproud 3 hours ago |
      My brew update/upgrade takes forever
    • noahbp 3 hours ago |
      The same criticism has been said of Deno and Pnpm and bun, and yet, despite all these years since their respective releases, node and npm remain slower than all three options.
      • never_inline 3 hours ago |
        Well, pnpm solves the storage issue, which is a more pressing reason to use it. (I don't know about deno/bun)
      • fleebee 2 hours ago |
        Yeah, but do they work? Last time I gave bun a chance their runtime had serious issues with frequent crashes. Faster package installation or spin-up time is meaningless if it comes at the cost of stability and compatibility.
        • alwillis 5 minutes ago |
          bun is my go to for npm packages; it’s so much better and faster than npm, it’s not funny.

          Never had any issues.

    • ziml77 2 hours ago |
      Agreed here. The speed bottleneck I run into is simply that there's often a lot of packages that need updating, so there's a lot to download. And if anything needs to be compiled from source then the time that takes will dominate (though I think everything I currently run is thankfully pre-built)
    • motorpixel 2 hours ago |
      If I have to deal with even the mention of another package manager in the cross-platform dev ecosystem I am going to snap
    • staticassertion 2 hours ago |
      I've wanted brew to be faster. It would be a nice QoL for me.
    • password4321 an hour ago |
    • rconti 4 minutes ago |
      I've been a lightweight homebrew user for many, many, many years now. I just use it to download or update a thing I need, once every 3-6mo.

      It constantly blows my mind how insanely long it takes just to do a few simple things on the fastest hardware I've ever owned in my life.

  • pxc 4 hours 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!
  • kassadin 4 hours ago |
    Do you choose compatibility or speed?

    nb info --cask codex-app

    nb: formula '--cask' not found

    nb: formula 'codex-app' not found

  • luizfelberti 3 hours 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

    • tomComb 3 hours 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 an hour 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.

  • alsetmusic 3 hours 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 3 hours 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

    • happyopossum an hour 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 35 minutes 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 9 minutes 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.
    • password4321 an hour ago |
      Yes MacPorts is the way. I switched after a new MacOS release meant mine was too old - brew update uninstalled a bunch of stuff I had been using then it stopped and let me know.

      There's also https://github.com/dortania/OpenCore-Legacy-Patcher for the adventurous.

    • maxkfranz an hour ago |
      You could use the OpenCode legacy patcher to upgrade to v15/Sequoia: https://dortania.github.io/OpenCore-Legacy-Patcher/
  • tantalor 3 hours ago |
    And why does speed matter in this case?
  • manlymuppet 2 hours 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 2 hours 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/Form...

    • fny an hour ago |
      It uses the Homebrew API and uses its own dependency resolver and linker to pull Homebrew's precompiled packages.
  • Onavo 2 hours 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 an hour 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 40 minutes ago |
    So, A) to what extent is this vibe coded? And B) what is "trilok.ai" where you download it from?
  • peytongreen_dev 30 minutes ago |
    The "compatible but implicitly relies on upstream infrastructure" tension plays out identically in Python packaging right now with uv. uv is 10-100x faster than pip, written in Rust, and speaks the same interface — pyproject.toml, requirements.txt, pip install semantics — but it's not pip. It calls PyPI's APIs directly rather than running any Python tooling. Same question: is that "pip compatible" or "a faster frontend to PyPI's infrastructure that pip happens to also use"?

    The Homebrew maintainer's point is valid but cuts both ways. If the underlying infrastructure (PyPI's simple API, Homebrew's bottle CDN) is stable and public, building faster frontends is valuable even if they have partial compatibility. The risk is fragility when the host infrastructure changes in ways the frontend doesn't anticipate — and that's a real risk worth naming clearly in the README rather than claiming full compatibility.

    uv has been pretty careful about this framing. The Nanobrew README calling itself "compatible with brew" is doing more work than it should.