Live data from Hacker News

Sapphire: Rust based package manager for macOS

github.com

221–230 of 311 posts

Re: Sapphire: Rust based package manager for macOS

#221
post #23

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…

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.

Re: Sapphire: Rust based package manager for macOS

#222
post #67

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.

1. I thought "Sapphire is a next‑generation, Rust‑powered package manager inspired by Homebrew" covered it pretty well. 2. It's a personal project. 3. It's explicitly declared as alpha software.

#1 is a "what", not a "why"

Re: Sapphire: Rust based package manager for macOS

#223

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.

The name of the project doesn't need to be the same as the CLI, e.g. Homebrew -> brew.

This could be Sapphire -> sap

Re: Sapphire: Rust based package manager for macOS

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

Re: Sapphire: Rust based package manager for macOS

#225

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.

Yeah that’s not possible.

Re: Sapphire: Rust based package manager for macOS

#226
post #23

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…

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.

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.

Re: Sapphire: Rust based package manager for macOS

#227

Earlier quoted context omitted.

> 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 ma…

> 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. Homebrew's traffic pattern is not a uniform distribution. Package updates go out, and users download those packages in structured ways: there are spikes for MDM-managed Homebrew installations, spikes for cronjobs and CI/CD systems, spikes at 9AM on different coasts when devel…

Could you parallelize intelligently based on these heuristics? Like, say, whitelist GitHub and S3 for parallelizing

Re: Sapphire: Rust based package manager for macOS

#228
post #23

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…

Any idea what's up with MacPorts lately? Packages I needed to install were uncharacteristically broken or out of date which wasn't a thing ever since I switched from Fink ages ago. Apple used to use MacPorts internally and put resources into but they stopped doing so?

Re: Sapphire: Rust based package manager for macOS

#229

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 l…

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.

Re: Sapphire: Rust based package manager for macOS

#230
post #131

Earlier quoted context omitted.

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.

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

[flagged]
Post reply on HN