Cool, but why not use https://mise.jdx.dev/ ?
Sapphire: Rust based package manager for macOS
91–100 of 311 posts
Re: Sapphire: Rust based package manager for macOS
#92It’s a real disservice to the project not to give a raison d’etre in the readme, or any kind of technical motivation / differences.
> 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.
It would be interesting to know if there are other goals though, e.g. UX improvements.
Re: Sapphire: Rust based package manager for macOS
#93With 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,…
> 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…
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 developers sign into their machines, etc.
(How much this matters is also not uniform: it matters somewhat less for GitHub Packages - they should have a hefty CDN - and it matters somewhat more for Casks, which tend to be large DMGs hosted on individual servers.)
Re: Sapphire: Rust based package manager for macOS
#94Homebrew 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 distrib…
Re: Sapphire: Rust based package manager for macOS
#95It’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.
Re: Sapphire: Rust based package manager for macOS
#96Cool, but why not use https://mise.jdx.dev/ ?
Re: Sapphire: Rust based package manager for macOS
#97Earlier quoted context omitted.
Homebrew is 99% IO-bound and this will be too. Installing (prebuilt) packages doesn't require much logic. If this tool supports parallel downloads, it will be 10x faster than Homebrew, but it won't have anything to do with the language. The issue is finding a hosting provider willing to be DDOS'd for the good of the open-source community.
> If this tool supports parallel downloads, it will be 10x faster than Homebrew, but it won't have anything to do with the language. If this is true, why are the Rust tools, on average, so much faster than the JS (or whatever) tools they replace? Hint: the answer hasn't just to do with the theoretical technical merits of the underlying platform, but also what type of developer they attract.
Re: Sapphire: Rust based package manager for macOS
#98Earlier quoted context omitted.
P2P protocols like BitTorrent are made for this kind of problem.
Sure. There's also a reason no major OSS packaging ecosystem uses these protocols: the only thing worse than a slow distribution scheme is an unreliable one. Combine that with the (reasonable) lack of a reward scheme for seeding an OSS packaging ecosystem, and you have a distribution mechanism that's significantly more brittle than the current "throw a lot of bandwidth at it" approach. (Among other technical challeng…
Generating additional metadata at bottle build time doesn't appear to be much of a technical challenge either.
Re: Sapphire: Rust based package manager for macOS
#99Re: Sapphire: Rust based package manager for macOS
#100This 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.
No different than the Windows registry, which apparently uses a honeybee / hive metaphor because some Windows dev hated bees and their teammates liked trolling them.