13 ms·

Sapphire: Rust based package manager for macOS

443 points by adamnemecek 1y ago

deleted 1y ago
[deleted]
nartho 1y ago
What is it doing better than homebrew ?
- adamnemecek 1y ago
  Right now probably not much, it's WIP.
  - carterschonwald 1y ago
    Having different project leadership is probably a big selling point ;)
    - adamnemecek 1y ago
      Does homebrew have bad leadership?
      - paradox460 1y ago
        Some of their leadership has been heavy handed with regards to unpopular decisions, like removing options from packages.
    - Henchman21 1y ago
      What exactly went down with homebrew? Suddenly my employer was pulling it from every device and I never really got a solid explanation of why! I've not been able to get anything meaningful from searching on my own, obviously. Someone help a guy out?
      - israrkhan 1y ago
        Homebrew itself is not bad, but it does allow users to install software from thirdparty sources, that are unvetted, or unverified. This could pose a security risk. I can see why some companies will disable homebrew. Especially for non-developers.
        no_wizard 1y ago
        I think they’re specifically asking about the project as opposed to the tool
        cassianoleal 1y ago
        Homebrew doesn't suddenly add that capability. It just facilitates it. If nothing else, it's easier to track what's been installed via brew than whatever the user may have curlbashed or untargzed to their home.
        mort96 1y ago
        So does sourceforge and GitHub and similar, are those blocked too?
  - gkfasdfasdf 1y ago
    I hope it is faster. Homebrew operations take forever for me.
  - carstenhag 1y ago
    Ok, but then what goals do you have with it? What are you trying to solve/improve upon?
- deleted 1y ago
  [deleted]
- StopDisinfo910 1y ago
  Given homebrew was strictly worse than the tool it displaced, I’m not sure it’s the right question to ask. MacOS package management is strictly marketing based.
  - user82747493 1y ago
    That’s not fair. Homebrew has been fantastic. It’s also open source, did they not accept your pull requests for these “improvements”?
    - StopDisinfo910 1y ago
      They spent months fuding MacPorts before putting in place exactly what MacPort was doing because it turns out it’s the right solution and despite that the ergonomic is still garbage (try installing packages outside of the default folder for a good laugh).
      - woodruffw 1y ago
        Who is "they"? I've never FUDed MacPorts, and in a decade of contributing to and maintaining Homebrew I can say honestly that I've never heard any other maintainer talk much about it beyond user experience. (Beyond anything else, Homebrew's biggest "win" over MacPorts was and probably is still UX and DX. The core technology of a packaging ecosystem is rarely itself the differentiator.)
        StopDisinfo910 1y ago
        Just go read the original announcements of homebrew. They expend at length about how Macport was wrong for shipping its own tool chain and homebrew was somehow superior for reusing the one shipped with MacOS (guess how it turned out). The fact that most packages completely broke if installed outside of /usr/local (itself a non sensical default) was just cherry on the cake. And let’s not talk about how everything broke if you didn’t update often enough so much so that there somehow is a command to try to bring things back to sanity. Homebrew is by far the worst package manager I have ever used. I’m still sour it somehow dragged away packagers from solutions which were better in every way by being promoted as the "default" solution.
- nottorp 1y ago
  I doesn't have to do anything better. It's in Rust and that should be the only reason you need to switch.
deleted 1y ago
[deleted]
benatkin 1y ago
FWIW the author of Homebrew is also working on a next generation package manager in rust: https://pkgx.dev/ https://pkgx.dev/ (beware facebook tracking and infinite AI slop)
- adamnemecek 1y ago
  Also in Rust, haha.
  - benatkin 1y ago
    I finally looked up the GitHub repo found some context about the website: https://github.com/pkgxdev/pantry/issues/5358 https://github.com/pkgxdev/pantry/issues/5358
- no_wizard 1y ago
  What’s the deal with the cautious warnings? Is homebrew being replaced by software developed using a “vibing coding” or what have you?
  - benatkin 1y ago
    if you see the issue I linked, there are a lot of thumbs up / thumbs down in the comments, it's not just me =)
    - no_wizard 1y ago
      I think I lack context enough that even the link doesn't make it very clear to me.
      - frollogaston 1y ago
        mxcl is the owner of this other project and also the original creator of Homebrew. Someone asked politely to remove a broken package from the list, mxcl gave an oddly combative response, then you see the rest.
- 1y ago
elcritch 1y ago
> 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.
- bhouston 1y ago
  My thoughts exactly. The main reason I find brew to be a bit slow is just a lack of parallelism with regards to downloads and installs. Rather brew does alternating and sequential D, I, D, I, D, I, when I wish it just kept downloading in the background when it is doing the installs. It would cut down the brew upgrade time by 30% or more at the cost of more disk space used during the process. But this one qualm I have isn't a result of its language implementation at all.
  - woodruffw 1y ago
    FWIW: a longstanding limitation for parallel downloads within Homebrew isn't architectural (it's not too hard to add!) but structural with respect to Homebrew's download sources: GitHub and others are very gracious with the amount of traffic we send their way, and we don't want to overtax services that have other major consuming parties. (This is a perverse countereffect: small projects can make performance decisions that Homebrew and other larger projects can't make, because they don't have a large install base that reveals the limitations of those decisions.)
    - bhouston 1y ago
      > FWIW: a longstanding limitation for parallel downloads within Homebrew isn't architectural (it's not too hard to add!) but structural with respect to Homebrew's download sources I have heard that before. Hmm.... I wonder if you can get away with not doing parallel downloads, but just keep the sequential downloads going in the background while it is installing a package? It is the pause in downloads during an install that I find is the main slow down in brew.
larusso 1y ago
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.
- skydhash 1y ago
  I loved macports, mostly because I wanted to create a new user account for a project and got bitten with the permissions thing by homebrew. I don’t mind typing sudo.
- fastball 1y ago
  Why didn't you like the project if it was a better project by most definitions of what makes a good package manager? e.g. what did you want from a package manager besides 1. easy to install packages 2. readily updated packages.
  - larusso 1y ago
    macports had the cleaner packages. Macports created its own base library so that packages are not based on the macOS system libraries which managed to break them when doing system updates with brew or when you decided to stay longer on an older macOS version. That meant that packages from macports took longer to install and compile. That was from the time when bottles where not a thing yet. Brew was fast but unstable. In my opinion the inferior project won. But to brews defence they also addressed the issues over the years. Don‘t have any sources at hand but I remember a time when the brew project compared itself to macports and pointed out that their faster because they don‘t recompile all base libraries etc etc. And they had to realize that this wasn‘t a great idea. Now packages are practically split between different os versions. And different bottles are served depending which macOS version you run. Edit: And I got reminded that it was possible to run and install packages for and from multiple users. Brew took over /usr/local/bin and other /usr/local/homebrew for the running user. Managing a system with multiple users with brew was and still is hard. With macports you needed sudo like with most other package managers. The sudo less nature was a huge deal for its adoption. And now maybe a security risk if you ask me.
azinman2 1y ago
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.
- motorest 1y ago
  > 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. This. There's a wave of projects whose only value proposition is this vacuous "let's reinvent the wheel in Rust" sales pitch, where nothing of value is proposed beyond throwing around the Rust buzzword.
  - IshKebab 1y ago
    Is it really necessary to restate the advantages of rewriting in Rust in every such project? Compared to Ruby programs Rust programs are faster, more robust, more maintainable, and easier to install. That's pretty much the same for any Rust rewrite (e.g. uv). It would be interesting to know if there are other goals though, e.g. UX improvements.
    - azinman2 1y ago
      The speed of homebrew has never been limiting factor (for me). I think there are far more important factors in what’s maintainable or not than language, and homebrew is very easy to install. There has to be more important reasons to replace a mature widely use project like homebrew.
      - koakuma-chan 1y ago
        The issue with homebrew is not the programming language. The issue is homebrew itself. It takes forever to install packages, auto-updates without prompting you, etc. Also on my Mac it's been broken for years. It tries to auto-update and gets stuck forever. https://github.com/orgs/Homebrew/discussions/1177 https://github.com/orgs/Homebrew/discussions/1177
alexykn 1y ago
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.
- jrochkind1 1y ago
  What makes you interested in a rust implementation of brew? I'm guessing it's that you hoping that it is eventually more performant -- are there specific areas of current brew you have identified as performance bottlenecks likely to eventually benefit from a rust implementation? Or any more info to share about assumptions/hopes that motivated this or any other motivations?
  - dijit 1y ago
    I say this from ignorance, but coming from a lineage of linux package managers; brew must be doing something wrong - and upon immediate introspection I doubt that its language specific. The performance of apt/dnf in comparison is surreal; but dnf (or at least yum, its predecessor) is written in Python; which has even worse performance characteristics than Ruby. Clearly something is wrong, I wonder how different they are architecturally.
hk1337 1y ago
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
- runjake 1y ago
  For the last 5 years (since Apple Silicon was released), Homebrew has installed to /opt/homebrew by default.
  - mort96 1y ago
    No, it only does that on Apple Silicon. To this day, if you run the latest Homebrew on an Intel Mac running the latest macOS, it will install to /usr/local.
    - runjake 1y ago
      The parent indicates in a comment that they use an Apple Silicon Mac[1]. I don't see a lot of engineers running Intel Macs anymore. I haven't seen any engineers who still use an Intel model, myself, and for quite some time. Especially when there are Apple Silicon options for well under $1,000 that highly outperform the Intel models. 1. https://news.ycombinator.com/item?id=43267210 https://news.ycombinator.com/item?id=43267210
      - KingMob 1y ago
        [flagged]
  - hk1337 1y ago
    I don’t want it there either. The install script is defines the install directory without anyway to override it. It sets it to /usr/local or /opt/homebrew depending on the result of uname command. I like it in ~/.brew where I have full permission to it and only my user.
mort96 1y ago
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.
- seumars 1y ago
  Agreed. Come to think of it Homebrew has pretty bad ergonomics in general. What i want is an overview of compiled binaries, where they are, and what their versions are. That’s it.
  - BowBun 1y ago
    `brew ls --versions` + `brew list | xargs brew list` Everything you need is there...
- alexykn 1y ago
  I will probably change the terminology at some point for this. For initially building it it is way easier to keep them the same though as trying to understand brew itself (at least for me) isn't so straight forward. It's a massive project
  - moritzwarhier 1y ago
    Kudos for your humility. I'd agree that the current homebrew terms are inappropriately whimsical and hard to grasp, but you are right in your intuition and goal, IMO. That is, taking care of the gears first and then carefully adjusting the public API.
- bartvk 1y ago
  Nowadays, normal users don't need to know. They just "brew install <name>".
  - 1y ago
coconut08 1y ago
[flagged]
- deleted 1y ago
  [deleted]
woodruffw 1y ago
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 https://news.ycombinator.com/item?id=43765605
- IshKebab 1y ago
  > 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 That doesn't make sense. As you say you're directing a huge volume of traffic so it makes no difference exactly when a user downloads a byte. It all gets smeared out. Only the total amount of data matters and that is unaffected by parallelism.
  - woodruffw 1y ago
selkin 1y ago
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.
- jamesgeck0 1y ago
  If I understand correctly, running a Debian-style stable repo would essentially require forking all distributed software and backporting security fixes to them. With many macOS users coming from a different communities than Debian users, I really wonder how well that would go over with the folks whose software was being distributed.
  - selkin 1y ago
    Caveat lector, as I didn't collect the data to back this, but I would be extremeley surprised to find more than a few dozen of non-cask packages in Homebrew that contain Macintosh only software.
- frollogaston 1y ago
  I mainly disagree with the Homebrew stance on sudo/root. They claim it's better to install everything under a user dir, but 10% of the time that doesn't work for whatever reason, and tons of users have screwed up their permissions trying to fix it. No other package manager has this issue.
  - selkin 1y ago
    I am not too fond of this design for reasons of privilege separation and FHS-alignment, but can accept it as most Homebrew users don't have their Macintosh computers used by multiple people.
oulipo 1y ago
Cool, but why not use https://mise.jdx.dev/ https://mise.jdx.dev/ ?
- Alifatisk 1y ago
  Because I haven’t heard of it until now?
- IshKebab 1y ago
  That's a totally different tool. Brew is a generic package manager that installs ... basically everything. Mise is specifically for managing compilers and associated tooling. You can't install libgmp or mplayer with Mise.
- trallnag 1y ago
  I'm still not sure if I like the fact that the package management part of mise relies on a bunch of third-party package managers / repositories like asdf, aqua,...
commandersaki 1y ago
If this provided support for multi-user setup without the user switching gymnastics of homebrew, then I'd be interested.
deleted 1y ago
[deleted]
hnarayanan 1y ago
I’m really happy with my MacPorts.
ansc 1y ago
I'm really rooting for this. I can't wait for Homebrew replacements, what a pain it is.
- monoid73 1y ago
  same here. brew’s been great historically but it’s gotten bloated and kinda slow. curious to see if sapphire can keep things lean without sacrificing compatibility.
- kccqzy 1y ago
  What is your pain point? If you don't elucidate your pain point, whatever the replacement is it might copy over that pain point.
whywhywhywhy 1y ago
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.
- jdeaton 1y ago
  Yeah i vote it should be rebranded “why”
  - alexykn 1y ago
    command: why install htop, -> install start: because you wan' it -> done: you got it Something like that you mean?
    - Asraelite 1y ago
      I would love if the way to respond "yes" to the CLI is "why not"
    - Ringz 1y ago
      Why not.
  - chucksmash 1y ago
    Perhaps _why?
  - Rodmine 1y ago
    Obvious joke is obvious... but it seems the "motivation" is to write a project in rust.
- alexykn 1y ago
  I know, probably will, also feel typing out sapphire for the command all the time is annoying + sapp would be weird. For me technical implementation comes first though. I'll do that when something comes to mind
frollogaston 1y ago
I just want the equivalent of `sudo apt-get install` on Mac, with the same exact commands.
- jen20 1y ago
  The thing you want then is `fink`, which literally uses dpkg and apt.
  - frollogaston 1y ago
    That sounds like what I want. Seems to only have "wip" support for the newer macOSes though. I also remember using the Debian packager on iPhone back in the golden age of jailbreaking.
    - jen20 1y ago
      Yeah, I thought I had edited my post to say it doesn't look to still be alive (apparently I did not!) - that's a shame, having diversity in this space is good.
alexykn 1y ago
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!
maartn 1y ago
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
- selkin 1y ago
  https://en.wikipedia.org/wiki/Alias_(command) https://en.wikipedia.org/wiki/Alias_(command)
  - maartn 1y ago
    Yeah, sure, bury UX tips in "also possible workarounds"
ARandomerDude 1y ago
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?
moonlion_eth 1y ago
wen linux
mrbonner 1y ago
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.
- nicce 1y ago
  Some GUI-based applications tend to require too much hassle with Nix so I personally install those with brew. But I still use home manager on top of everything.
- KingMob 1y ago
  Funny, I gave up on nix-darwin recently after a year, and went back to homebrew. Trying to manage nix was more work than I wanted to do.
cantrecallmypwd 1y ago
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.
rewgs 1y ago
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
renecito 1y ago
so cool!, but can you invert a binary tree? /s
vmsp 1y ago
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.
xyst 1y ago
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.
microflash 1y ago
There’s also `cart` : https://github.com/heywoodlh/cart https://github.com/heywoodlh/cart I especially like their claim of being unprivileged. Very early stages just like Sapphire.
TriangleEdge 1y ago
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.
- adamnemecek 1y ago
  Yeah that’s not possible.
MelodyUwU 1y ago
still, nothing can replace macports for me, ever
- a-french-anon 1y ago
  I use Macports on my work Macbook, but I'd love for Portage prefix to be fully functional on ARM Mac, personally. The tool interface is just so much better.
  - MelodyUwU 1y ago
    on contrast, I have a 32bit macbook pro on snow leopard, so none of these shiny tools can be even remotely useful to me (sapphire being arm only? yeah, that)
snekcaseenjoyer 1y ago
Looks awesome. Thanks for your hard work, I will try this out at some point :)
MarkMarine 1y ago
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
fkbrw 1y ago
[flagged]
exabrial 1y ago
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.
smetannik 1y ago
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?
rbanffy 1y ago
I think the best replacement is still MacPorts.
indiansdontwipe 1y ago
[flagged]
- dgfl 1y ago
  That’s right. Back in the day we used to have only clear and descriptive names, like C and GNU.
okcdz 1y ago
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.

443 points by adamnemecek 1y ago

deleted 1y ago

[deleted]

nartho 1y ago

What is it doing better than homebrew ?

adamnemecek 1y ago
Right now probably not much, it's WIP.
- carterschonwald 1y ago
  Having different project leadership is probably a big selling point ;)
  - adamnemecek 1y ago
    Does homebrew have bad leadership?
    - paradox460 1y ago
      Some of their leadership has been heavy handed with regards to unpopular decisions, like removing options from packages.
  - Henchman21 1y ago
    What exactly went down with homebrew? Suddenly my employer was pulling it from every device and I never really got a solid explanation of why! I've not been able to get anything meaningful from searching on my own, obviously. Someone help a guy out?
    - israrkhan 1y ago
      Homebrew itself is not bad, but it does allow users to install software from thirdparty sources, that are unvetted, or unverified. This could pose a security risk. I can see why some companies will disable homebrew. Especially for non-developers.
      - no_wizard 1y ago
        I think they’re specifically asking about the project as opposed to the tool
      - cassianoleal 1y ago
        Homebrew doesn't suddenly add that capability. It just facilitates it. If nothing else, it's easier to track what's been installed via brew than whatever the user may have curlbashed or untargzed to their home.
      - mort96 1y ago
        So does sourceforge and GitHub and similar, are those blocked too?
- gkfasdfasdf 1y ago
  I hope it is faster. Homebrew operations take forever for me.
- carstenhag 1y ago
  Ok, but then what goals do you have with it? What are you trying to solve/improve upon?
deleted 1y ago
[deleted]
StopDisinfo910 1y ago
Given homebrew was strictly worse than the tool it displaced, I’m not sure it’s the right question to ask. MacOS package management is strictly marketing based.
- user82747493 1y ago
  That’s not fair. Homebrew has been fantastic. It’s also open source, did they not accept your pull requests for these “improvements”?
  - StopDisinfo910 1y ago
    They spent months fuding MacPorts before putting in place exactly what MacPort was doing because it turns out it’s the right solution and despite that the ergonomic is still garbage (try installing packages outside of the default folder for a good laugh).
    - woodruffw 1y ago
      Who is "they"? I've never FUDed MacPorts, and in a decade of contributing to and maintaining Homebrew I can say honestly that I've never heard any other maintainer talk much about it beyond user experience. (Beyond anything else, Homebrew's biggest "win" over MacPorts was and probably is still UX and DX. The core technology of a packaging ecosystem is rarely itself the differentiator.)
      - StopDisinfo910 1y ago
        Just go read the original announcements of homebrew. They expend at length about how Macport was wrong for shipping its own tool chain and homebrew was somehow superior for reusing the one shipped with MacOS (guess how it turned out). The fact that most packages completely broke if installed outside of /usr/local (itself a non sensical default) was just cherry on the cake. And let’s not talk about how everything broke if you didn’t update often enough so much so that there somehow is a command to try to bring things back to sanity. Homebrew is by far the worst package manager I have ever used. I’m still sour it somehow dragged away packagers from solutions which were better in every way by being promoted as the "default" solution.
nottorp 1y ago
I doesn't have to do anything better. It's in Rust and that should be the only reason you need to switch.

deleted 1y ago

[deleted]

benatkin 1y ago

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

adamnemecek 1y ago
Also in Rust, haha.
- benatkin 1y ago
  I finally looked up the GitHub repo found some context about the website: https://github.com/pkgxdev/pantry/issues/5358 https://github.com/pkgxdev/pantry/issues/5358
no_wizard 1y ago
What’s the deal with the cautious warnings? Is homebrew being replaced by software developed using a “vibing coding” or what have you?
- benatkin 1y ago
  if you see the issue I linked, there are a lot of thumbs up / thumbs down in the comments, it's not just me =)
  - no_wizard 1y ago
    I think I lack context enough that even the link doesn't make it very clear to me.
    - frollogaston 1y ago
      mxcl is the owner of this other project and also the original creator of Homebrew. Someone asked politely to remove a broken package from the list, mxcl gave an oddly combative response, then you see the rest.
1y ago

elcritch 1y ago

> 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.

bhouston 1y ago
My thoughts exactly. The main reason I find brew to be a bit slow is just a lack of parallelism with regards to downloads and installs. Rather brew does alternating and sequential D, I, D, I, D, I, when I wish it just kept downloading in the background when it is doing the installs. It would cut down the brew upgrade time by 30% or more at the cost of more disk space used during the process. But this one qualm I have isn't a result of its language implementation at all.
- woodruffw 1y ago
  FWIW: a longstanding limitation for parallel downloads within Homebrew isn't architectural (it's not too hard to add!) but structural with respect to Homebrew's download sources: GitHub and others are very gracious with the amount of traffic we send their way, and we don't want to overtax services that have other major consuming parties. (This is a perverse countereffect: small projects can make performance decisions that Homebrew and other larger projects can't make, because they don't have a large install base that reveals the limitations of those decisions.)
  - bhouston 1y ago
    > FWIW: a longstanding limitation for parallel downloads within Homebrew isn't architectural (it's not too hard to add!) but structural with respect to Homebrew's download sources I have heard that before. Hmm.... I wonder if you can get away with not doing parallel downloads, but just keep the sequential downloads going in the background while it is installing a package? It is the pause in downloads during an install that I find is the main slow down in brew.

larusso 1y ago

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.

skydhash 1y ago
I loved macports, mostly because I wanted to create a new user account for a project and got bitten with the permissions thing by homebrew. I don’t mind typing sudo.
fastball 1y ago
Why didn't you like the project if it was a better project by most definitions of what makes a good package manager? e.g. what did you want from a package manager besides 1. easy to install packages 2. readily updated packages.
- larusso 1y ago
  macports had the cleaner packages. Macports created its own base library so that packages are not based on the macOS system libraries which managed to break them when doing system updates with brew or when you decided to stay longer on an older macOS version. That meant that packages from macports took longer to install and compile. That was from the time when bottles where not a thing yet. Brew was fast but unstable. In my opinion the inferior project won. But to brews defence they also addressed the issues over the years. Don‘t have any sources at hand but I remember a time when the brew project compared itself to macports and pointed out that their faster because they don‘t recompile all base libraries etc etc. And they had to realize that this wasn‘t a great idea. Now packages are practically split between different os versions. And different bottles are served depending which macOS version you run. Edit: And I got reminded that it was possible to run and install packages for and from multiple users. Brew took over /usr/local/bin and other /usr/local/homebrew for the running user. Managing a system with multiple users with brew was and still is hard. With macports you needed sudo like with most other package managers. The sudo less nature was a huge deal for its adoption. And now maybe a security risk if you ask me.

azinman2 1y ago

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.

motorest 1y ago
> 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. This. There's a wave of projects whose only value proposition is this vacuous "let's reinvent the wheel in Rust" sales pitch, where nothing of value is proposed beyond throwing around the Rust buzzword.
- IshKebab 1y ago
  Is it really necessary to restate the advantages of rewriting in Rust in every such project? Compared to Ruby programs Rust programs are faster, more robust, more maintainable, and easier to install. That's pretty much the same for any Rust rewrite (e.g. uv). It would be interesting to know if there are other goals though, e.g. UX improvements.
  - azinman2 1y ago
    The speed of homebrew has never been limiting factor (for me). I think there are far more important factors in what’s maintainable or not than language, and homebrew is very easy to install. There has to be more important reasons to replace a mature widely use project like homebrew.
    - koakuma-chan 1y ago
      The issue with homebrew is not the programming language. The issue is homebrew itself. It takes forever to install packages, auto-updates without prompting you, etc. Also on my Mac it's been broken for years. It tries to auto-update and gets stuck forever. https://github.com/orgs/Homebrew/discussions/1177 https://github.com/orgs/Homebrew/discussions/1177

alexykn 1y ago

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.

jrochkind1 1y ago
What makes you interested in a rust implementation of brew? I'm guessing it's that you hoping that it is eventually more performant -- are there specific areas of current brew you have identified as performance bottlenecks likely to eventually benefit from a rust implementation? Or any more info to share about assumptions/hopes that motivated this or any other motivations?
- dijit 1y ago
  I say this from ignorance, but coming from a lineage of linux package managers; brew must be doing something wrong - and upon immediate introspection I doubt that its language specific. The performance of apt/dnf in comparison is surreal; but dnf (or at least yum, its predecessor) is written in Python; which has even worse performance characteristics than Ruby. Clearly something is wrong, I wonder how different they are architecturally.

hk1337 1y ago

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

runjake 1y ago
For the last 5 years (since Apple Silicon was released), Homebrew has installed to /opt/homebrew by default.
- mort96 1y ago
  No, it only does that on Apple Silicon. To this day, if you run the latest Homebrew on an Intel Mac running the latest macOS, it will install to /usr/local.
  - runjake 1y ago
    The parent indicates in a comment that they use an Apple Silicon Mac[1]. I don't see a lot of engineers running Intel Macs anymore. I haven't seen any engineers who still use an Intel model, myself, and for quite some time. Especially when there are Apple Silicon options for well under $1,000 that highly outperform the Intel models. 1. https://news.ycombinator.com/item?id=43267210 https://news.ycombinator.com/item?id=43267210
    - KingMob 1y ago
      [flagged]
- hk1337 1y ago
  I don’t want it there either. The install script is defines the install directory without anyway to override it. It sets it to /usr/local or /opt/homebrew depending on the result of uname command. I like it in ~/.brew where I have full permission to it and only my user.

mort96 1y ago

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.

seumars 1y ago
Agreed. Come to think of it Homebrew has pretty bad ergonomics in general. What i want is an overview of compiled binaries, where they are, and what their versions are. That’s it.
- BowBun 1y ago
  `brew ls --versions` + `brew list | xargs brew list` Everything you need is there...
alexykn 1y ago
I will probably change the terminology at some point for this. For initially building it it is way easier to keep them the same though as trying to understand brew itself (at least for me) isn't so straight forward. It's a massive project
- moritzwarhier 1y ago
  Kudos for your humility. I'd agree that the current homebrew terms are inappropriately whimsical and hard to grasp, but you are right in your intuition and goal, IMO. That is, taking care of the gears first and then carefully adjusting the public API.
bartvk 1y ago
Nowadays, normal users don't need to know. They just "brew install <name>".
- 1y ago

coconut08 1y ago

[flagged]

deleted 1y ago
[deleted]

woodruffw 1y ago

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 https://news.ycombinator.com/item?id=43765605

IshKebab 1y ago
> 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 That doesn't make sense. As you say you're directing a huge volume of traffic so it makes no difference exactly when a user downloads a byte. It all gets smeared out. Only the total amount of data matters and that is unaffected by parallelism.
- woodruffw 1y ago

selkin 1y ago

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.

jamesgeck0 1y ago
If I understand correctly, running a Debian-style stable repo would essentially require forking all distributed software and backporting security fixes to them. With many macOS users coming from a different communities than Debian users, I really wonder how well that would go over with the folks whose software was being distributed.
- selkin 1y ago
  Caveat lector, as I didn't collect the data to back this, but I would be extremeley surprised to find more than a few dozen of non-cask packages in Homebrew that contain Macintosh only software.
frollogaston 1y ago
I mainly disagree with the Homebrew stance on sudo/root. They claim it's better to install everything under a user dir, but 10% of the time that doesn't work for whatever reason, and tons of users have screwed up their permissions trying to fix it. No other package manager has this issue.
- selkin 1y ago
  I am not too fond of this design for reasons of privilege separation and FHS-alignment, but can accept it as most Homebrew users don't have their Macintosh computers used by multiple people.

oulipo 1y ago

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

Alifatisk 1y ago
Because I haven’t heard of it until now?
IshKebab 1y ago
That's a totally different tool. Brew is a generic package manager that installs ... basically everything. Mise is specifically for managing compilers and associated tooling. You can't install libgmp or mplayer with Mise.
trallnag 1y ago
I'm still not sure if I like the fact that the package management part of mise relies on a bunch of third-party package managers / repositories like asdf, aqua,...

commandersaki 1y ago

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

deleted 1y ago

[deleted]

hnarayanan 1y ago

I’m really happy with my MacPorts.

ansc 1y ago

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

monoid73 1y ago
same here. brew’s been great historically but it’s gotten bloated and kinda slow. curious to see if sapphire can keep things lean without sacrificing compatibility.
kccqzy 1y ago
What is your pain point? If you don't elucidate your pain point, whatever the replacement is it might copy over that pain point.

whywhywhywhy 1y ago

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.

jdeaton 1y ago
Yeah i vote it should be rebranded “why”
- alexykn 1y ago
  command: why install htop, -> install start: because you wan' it -> done: you got it Something like that you mean?
  - Asraelite 1y ago
    I would love if the way to respond "yes" to the CLI is "why not"
  - Ringz 1y ago
    Why not.
- chucksmash 1y ago
  Perhaps _why?
- Rodmine 1y ago
  Obvious joke is obvious... but it seems the "motivation" is to write a project in rust.
alexykn 1y ago
I know, probably will, also feel typing out sapphire for the command all the time is annoying + sapp would be weird. For me technical implementation comes first though. I'll do that when something comes to mind

frollogaston 1y ago

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

jen20 1y ago
The thing you want then is `fink`, which literally uses dpkg and apt.
- frollogaston 1y ago
  That sounds like what I want. Seems to only have "wip" support for the newer macOSes though. I also remember using the Debian packager on iPhone back in the golden age of jailbreaking.
  - jen20 1y ago
    Yeah, I thought I had edited my post to say it doesn't look to still be alive (apparently I did not!) - that's a shame, having diversity in this space is good.

alexykn 1y ago

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!

maartn 1y ago

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

selkin 1y ago
https://en.wikipedia.org/wiki/Alias_(command) https://en.wikipedia.org/wiki/Alias_(command)
- maartn 1y ago
  Yeah, sure, bury UX tips in "also possible workarounds"

ARandomerDude 1y ago

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?

moonlion_eth 1y ago

wen linux

mrbonner 1y ago

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.

nicce 1y ago
Some GUI-based applications tend to require too much hassle with Nix so I personally install those with brew. But I still use home manager on top of everything.
KingMob 1y ago
Funny, I gave up on nix-darwin recently after a year, and went back to homebrew. Trying to manage nix was more work than I wanted to do.

cantrecallmypwd 1y ago

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.

rewgs 1y ago

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

renecito 1y ago

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

vmsp 1y ago

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.

xyst 1y ago

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.

microflash 1y ago

There’s also `cart` : https://github.com/heywoodlh/cart https://github.com/heywoodlh/cart I especially like their claim of being unprivileged. Very early stages just like Sapphire.

TriangleEdge 1y ago

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.

adamnemecek 1y ago
Yeah that’s not possible.

MelodyUwU 1y ago

still, nothing can replace macports for me, ever

a-french-anon 1y ago
I use Macports on my work Macbook, but I'd love for Portage prefix to be fully functional on ARM Mac, personally. The tool interface is just so much better.
- MelodyUwU 1y ago
  on contrast, I have a 32bit macbook pro on snow leopard, so none of these shiny tools can be even remotely useful to me (sapphire being arm only? yeah, that)

snekcaseenjoyer 1y ago

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

MarkMarine 1y ago

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

fkbrw 1y ago

[flagged]

exabrial 1y ago

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.

smetannik 1y ago

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?

rbanffy 1y ago

I think the best replacement is still MacPorts.

indiansdontwipe 1y ago

[flagged]

dgfl 1y ago
That’s right. Back in the day we used to have only clear and descriptive names, like C and GNU.

okcdz 1y ago

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.