Cool, but why not use https://mise.jdx.dev/ ?
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,...
Sapphire: Rust based package manager for macOS
111–120 of 311 posts
Re: Sapphire: Rust based package manager for macOS
#112It’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.
“ Sapphire is a next‑generation, Rust‑powered package manager inspired by Homebrew”
Doesn’t tell me how it differs. What makes this next generation? Just the programming language?
If it’s just a for fun personal project that no one else is supposed to use, I’m not sure why it’s on HN.
Re: Sapphire: Rust based package manager for macOS
#113Anyway, 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!
Re: Sapphire: Rust based package manager for macOS
#114Hey, 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 A…
Cool project, good luck with it!
If I may surface one use case: Several years ago I had to manage a bunch of Macs for CI jobs. The build process (Unreal's UAT) didn't support running more than one build process at a time, and Docker was really slow, so I'd hoped to use different user accounts to bypass that and get some parallelization gains. Homebrew made that very difficult with its penchant for system-wide installs. So a feature request: I'd love to see a competitive package manager that limits itself to operating somewhere (overridable) in the user's home directory.
Re: Sapphire: Rust based package manager for macOS
#115This 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.
Cute names for standard things is one of my software bug bears, i.e. pet peeves, i.e. annoyances. Ruby gems and rust crates and something something beans. It is cute jargon and it annoys me to hide the definition inside a language specific terminology.
Re: Sapphire: Rust based package manager for macOS
#116Earlier quoted context omitted.
> 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.
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.
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.
Re: Sapphire: Rust based package manager for macOS
#117I'm really rooting for this. I can't wait for Homebrew replacements, what a pain it is.
What is your pain point? If you don't elucidate your pain point, whatever the replacement is it might copy over that pain point.
Re: Sapphire: Rust based package manager for macOS
#118Consider 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.
Re: Sapphire: Rust based package manager for macOS
#119Hey, 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 A…
Cool project, good luck with it! If I may surface one use case: Several years ago I had to manage a bunch of Macs for CI jobs. The build process (Unreal's UAT) didn't support running more than one build process at a time, and Docker was really slow, so I'd hoped to use different user accounts to bypass that and get some parallelization gains. Homebrew made that very difficult with its penchant for system-wide install…
Initial idea for this really came from my dayjob too, we have macs but no way to centrally manage them. The client / server part for the declarative system manager I want to build on top of this is quite far out yet though. At least several months
Re: Sapphire: Rust based package manager for macOS
#120Consider 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.
Yeah i vote it should be rebranded “why”