from Hacker News

Sapphire: Rust based package manager for macOS

by adamnemecek on 4/22/25, 6:39 PM with 290 comments

• by alexykn on 4/22/25, 7:18 PM

  Hey, so I built this thing, most of it at so far at least. And yeah, right now it isn't doing many things better than Homebrew.

  Setting of relative paths for bottle installs is still not perfect, well it works for every bottle I have tested except rust. Getting bottles working 100% is very doable though imo.

  Build from source formulae is still pretty f*ed + I do not know if it is really feasible given that the json API lacks information there and a full on Ruby -> Rust transpiler is way out of scope. Will probably settle for automatic build system detection based on archive structure there. + Maybe do my own version of the .rb scripts but in a more general machine readable format, not .rs lol

  Casks seem to work but I have only tested some .dmg -> .app ones and .pkg installers so far though. As with bottles 100% doable.

  Given that almost all formulae are available as bottles for modern ARM mac this could become a fully featured package manager. Actually didn't think so many people would look at it, started building it for myself because Homebrew just isn't cutting it for what I want.

  Started working on a declarative package + system manager for mac because I feel ansible is overkill for one machine and not really made for that and nix-darwin worms itself into the system so deep. Wrapping Brew commands was abysmally slow though so I started working on this and by now I am deep enough in I won't stop xD

  Anyway I am grateful for every bug report, Issue and well meaning pull request.

• by woodruffw on 4/22/25, 7:37 PM

  With my Homebrew hat on, but not speaking for others: I think this is pretty cool, and demonstrates something that we've discussed indirectly for years.

  At its core, there are really two parts to Homebrew:

  1. There's the client side, i.e. `brew`, which 99.9% of users stick to happy paths (bottle installs, supported platforms) within. These users could be supported with relative ease by a small native-code installer, since the majority of the work done by the installer in the happy path is fetching bottles, exploding them, and doing a bit of relocation.

  2. There's literally everything else, i.e. all of the developer, repository, and CI/CD machinery that keeps homebrew-core humming. This is the largely invisible infrastructure that makes `brew install` work smoothly, and it's very hard to RIIR (in a large part because it's tied heavily to the formula DSL, which is arbitrary Ruby).

  (1) is a nice experimental space, because Homebrew does (IMO) a decent job of isolating the client-facing side from the complexity of (2). However, (2) is where the meat-and-potatoes of packaging happens, and where Homebrew's differentiators really lie (specifically, in how easy it is to contribute new packages and bump existing ones).

  Edit: Another noteworthy aspect here around performance: I mentioned this in another comment[1], but parallel downloads of things like bottles and DMGs is not an architectural limitation of Homebrew itself, but instead a conscious decision to trade some install speed for courtesy towards the services we fetch from (including GitHub itself). Smaller projects can sidestep this because they're not directing nearly the same degree of volume; I think this project will discover if/when its volumes grow that it will need to serialize downloads to avoid being throttled or outright limited.

  [1]: https://news.ycombinator.com/item?id=43765605

• by mort96 on 4/22/25, 7:29 PM

  This looks like a fun little project, nice work!

  I'm not a big fan of keeping the Homebrew terminology though. I never know what a formula, keg, cask, cellar, tap or bottle is. Why not keep to the standard terms of package and repository etc? I don't know beer brewing terminology or how beer brewing is analogous to package management, and I honestly wish that it wasn't something which my tools expect me to learn.

• by larusso on 4/22/25, 7:16 PM

  I was a macports user but had to switch to homebrew because most new projects went there and it was generally easier to write Formulars etc. But I never really liked the project. I think writing a new package manager on top of brew infrastructure won‘t create a better setup. I don‘t know if all casks and Formulars only use the DSL stanzas or if still some use custom ruby functions and helpers. Because otherwise this new tool might need to eval ruby scripts for backwards compatibility.

• by ARandomerDude on 4/22/25, 9:39 PM

  Suggestion: create a Goals/Motivation/Rationale section in the README. What are the problems with Homebrew you're trying to solve? Why should a prospective user install and try this tool instead of staying with Homebrew?

• by selkin on 4/22/25, 8:12 PM

  Homebrew sure has room for improvement, as most software does, and I appreciate every effort to replace and renew what we have with something better. But my own grievances with Homebrew isn't with the codebase itself.

  What discourages me from using Homebrew is the intent and the mindset of its developers and packagers, who, I think, see their goal building an "unstable" distribution, as Debian defines it: "[a distribution that] is run by developers and those who like to live on the edge".

  I am not blaming the Homebrew developers for building a Sid rather than Bookworm. Some people want just that. Heck, I used to run Debian Sid myself, but have lost my patience for maintaining my own computers since: I am kept busy enough by fixing the software I write, I don't want to spend more time fixing software I did not.

• by mrbonner on 4/22/25, 10:29 PM

  I used to be a big fan of Homebrew but switch to Nix about 2 years ago. For the most part, it works great with home manager for me. Many tools can be installed with breeze just like breeze albeit a bit quicker. The critical thing for me is that Nix doesn't polute my Mac environment like Brew does. But, I admit that this is just for tools. For dev environment I usually just fall back to the language specific methods like cargo, uv or npm.

• by alexykn on 4/22/25, 8:45 PM

  Anyway, please do not expect progress to be too rapid. I have a full time job and do most work on this on weekends. I fully intend to make it a stable, "finished" (as much as this is possible in software) thing, it will take a while though. If anyone want's to help out I do open the bugs I find as Issues to keep track and give people an idea of things that do not work. Good Night!

• by whywhywhywhy on 4/22/25, 8:48 PM

  Consider rebranding to a 4 letter name or even better a 3 letter one.

  I know it sounds dumb but uv was smart to go shorter than pip and sapphire feels heavier than brew no matter what it does after typing that.

• by TriangleEdge on 4/23/25, 3:20 AM

  In my experience, rewriting software doesn't work. You should replace the components iteratively in Homebrew itself if you want your ideas to succeed. I doubt your software will see any major adoption just because you wrote it in some other language. The word Homebrew is culturally significant in hacker groups as well and sapphire is not.

• by hnarayanan on 4/22/25, 8:31 PM

  I’m really happy with my MacPorts.

• by cantrecallmypwd on 4/22/25, 10:40 PM

  This isn't a HB replacement, it's just using HB binaries. It doesn't replace HB at all. HB and this aren't full package managers when they don't officially or technically support building from source or working independently of another project's infrastructure.

  A decent full package manager would support a simple, shell-like DSL like say Alpine or Arch, concurrent and parallel phases (such as downloads/builds/installs), multiple versions, reproducible builds, building from source, build acceleration, security auditing, patch management, and package cryptographic signatures (not hashes or signing of hashes).

  Nix is theoretically amazing but the barrier-to-entry and gotchas for popular use make it self-limiting. Simplicity in particular areas is a price that is often paid for popularity.

• by maartn on 4/22/25, 9:19 PM

  Please give it an easier command name than ‘sapphire’ if you want to win people over to use it. Double in size and three times as hard to remember (or type) than ‘brew’. Even cli peeps are still just people

• by hk1337 on 4/22/25, 7:21 PM

  I wish homebrew was a little more friendly to installing in a directory other than what the installer sets. I used to have a lot of permissions issues back when /usr/local was the only directory and none since I started installing it in ~/.brew

• by microflash on 4/23/25, 3:01 AM

  There’s also `cart` : https://github.com/heywoodlh/cart

  I especially like their claim of being unprivileged. Very early stages just like Sapphire.

• by rewgs on 4/22/25, 11:03 PM

  Really glad to see that someone has started on a Mac package manager written in Rust.

  A couple purely superficial suggestions (echoing some other comments here):

  - Lose the Brew terminology, especially if the name of the project isn't a synonym of "brew." - Change the name in general. "Sapphire" makes me think of "Ruby." IMO the obvious name is MacPac :p

• by commandersaki on 4/22/25, 8:27 PM

  If this provided support for multi-user setup without the user switching gymnastics of homebrew, then I'd be interested.

• by benatkin on 4/22/25, 7:02 PM

  FWIW the author of Homebrew is also working on a next generation package manager in rust: https://pkgx.dev/ (beware facebook tracking and infinite AI slop)

• by vmsp on 4/22/25, 11:40 PM

  Homebrew was kind of slow, at one point, but I find that it works pretty well these days. Still, this is pretty cool and competitions is always good.

  Interestingly, I always imagined that a would-be replacement would come written in Swift. I guess I was wrong.

• by okcdz on 4/25/25, 6:43 AM

  Sounds good. But what are the advantages of implementing a package manager in Rust? I'd think languages with dynamic features would be more extensible and easier to iterate on.

• by MarkMarine on 4/23/25, 8:11 AM

  Why is parity with home brew the bar? Add something else great, like the ability to pin versions and not always install everything at head. Give me a reason to stop using home brew

• by smetannik on 4/23/25, 2:22 PM

  One small note - it’s quite easy to make a mistake typing “sapphire” command, especially if you have dyslexia.

  Is it possible to have more short command name?

• by oulipo on 4/22/25, 8:21 PM

  Cool, but why not use https://mise.jdx.dev/ ?

• by frollogaston on 4/22/25, 8:41 PM

  I just want the equivalent of `sudo apt-get install` on Mac, with the same exact commands.

• by exabrial on 4/23/25, 1:36 PM

  I used to donate to the Homebrew project and actually liked it, until it's enshitification a few years ago.

  * excessive superflurious animations? hell yeah

  * emojis everywhere? of course!

  * forced updates on by default

  * breaking updates? thanks your problem noob. Try to keep up.

  * versioning? lol, this isn't NASA

  * backwards compatibility? Lol. come on, we redesigned the standard, the right way, the 5th time this time.

  Its easy to criticize open source when you're not contributing, but thats why I sent my dollars over there, as I couldn't donate my time. Frustrating.

• by snekcaseenjoyer on 4/23/25, 7:18 AM

  Looks awesome. Thanks for your hard work, I will try this out at some point :)

• by rbanffy on 4/23/25, 2:44 PM

  I think the best replacement is still MacPorts.

• by MelodyUwU on 4/23/25, 6:57 AM

  still, nothing can replace macports for me, ever

• by moonlion_eth on 4/22/25, 9:51 PM

  wen linux

• by elcritch on 4/22/25, 7:15 PM

  > WARNING: ALPHA SOFTWARE > Sapphire is experimental, under heavy development, and may be unstable. Use at your own risk!

  Ruby seems fine for brew. Does this do anything else better? Ruby makes it easy to write recipes for it which is a huge boon for a package manager.

• by azinman2 on 4/22/25, 7:18 PM

  It’s a real disservice to the project not to give a raison d’etre in the readme, or any kind of technical motivation / differences.

• by nartho on 4/22/25, 6:49 PM

  What is it doing better than homebrew ?

• by renecito on 4/22/25, 11:17 PM

  so cool!, but can you invert a binary tree? /s

• by ansc on 4/22/25, 8:38 PM

  I'm really rooting for this. I can't wait for Homebrew replacements, what a pain it is.

• by xyst on 4/22/25, 11:42 PM

  Cool project. Definitely starring. But I’m sticking with nix to manage across systems.

  Yes a steep learning curve but once you have it set up then it’s easy to sync across devices.