Live data from Hacker News

Sapphire: Rust based package manager for macOS

github.com

171–180 of 311 posts

Re: Sapphire: Rust based package manager for macOS

#171
post #163

Earlier quoted context omitted.

> My understanding is that there's no standard way to update a torrent file; you re-roll a new file with the changes. Kinda. You do create a new torrent, but you distribute it in a way that to a swarm member is functionally equivalent to updating an old one. Check out BEP-0039 and BEP-0046 which respectively cover the HTTP and DHT mechanisms for updating torrents: https://www.bittorrent.org/beps/bep_0039.html https:/…

That’s very cool! That addresses the basic update issue, although I would be surprised if there was a production-ready Ruby library for torrents that included these. The state of HTTP(S) in Ruby is sad enough :-) (There’s also still the state/seeding problem and its collision with user expectations around brew getting faster, or at least not any slower.)

I agree with you about package manager usage patterns being a poor fit for seeding by end users. I definitely wouldn't want my computer to participate.

I could see institutional seeders doing it as a way to donate bandwidth though, like a CDN that's built into the distribution protocol instead of getting load-balanced to Microsoft's nearest PoP when hitting a GitHub `ghcr.io` URI like Homebrew does today. Or even better, use that as an HTTP Seed (BEP-0019) to combine benefits of both :)

https://www.bittorrent.org/beps/bep_0019.html

Re: Sapphire: Rust based package manager for macOS

#172
post #169

Earlier quoted context omitted.

IIRC the main reason here is that brew path is hardcoded during the build process of packages, which means that you wouldn't be able to use bottles. I didn't check, but there is a chance that path is also hardcoded in (some) formulae, so even building from the source might not help here.

You could run the build process with chroot or inside Docker, so that the hardcoded paths actually resolve to a designated subdirectory.

Incidentally, that’s what is usually done in Nixpkgs in similar situations when there’s no better alternative, see buildFHSEnv et al.

Re: Sapphire: Rust based package manager for macOS

#173
post #26

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

oh, I guess this is why the nix installer creates 32 macOS users called _nixbld$N

Re: Sapphire: Rust based package manager for macOS

#174
post #26

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

You mentioned a declarative package manager for Mac. I've really liked using Homebrew Bundle [1] over the last couple years. It's about the level of declarative that I've wanted and has made it really easy to bootstrap new laptop or VM (since it also works on Linux). The format for a Brewfile was pretty easy to figure out.

The way I ended up using it was that `brew install` would temporarily install something, without adding it to my Brewfile. And a little `brew add` wrapper would add the package to my Brewfile to keep it on the system permanently. That part with the wrapper could have used some love and would be a nice fit for a new brew-compatible frontend IMO. Maybe you could expand on that for Sapphire, if that also scratches your declarative itch?

[1] https://docs.brew.sh/Brew-Bundle-and-Brewfile

Re: Sapphire: Rust based package manager for macOS

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

Re: Sapphire: Rust based package manager for macOS

#176

Earlier quoted context omitted.

What’s the deal with the cautious warnings? Is homebrew being replaced by software developed using a “vibing coding” or what have you?

if you see the issue I linked, there are a lot of thumbs up / thumbs down in the comments, it's not just me =)

I think I lack context enough that even the link doesn't make it very clear to me.

Re: Sapphire: Rust based package manager for macOS

#177
post #44

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.

Yes! A thousand times yes. Homebrew terminology makes absolutely zero sense whatsoever and I find it irritating when I encounter it every now and then (like when a package says tap something and then install it blah blah)

I wish they’d just call them binaries, macOS packages, packages, gui-packages, etc.

To be clear, all those words are also jargon but they’re reusable concepts across software.

Re: Sapphire: Rust based package manager for macOS

#178

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…

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.

Re: Sapphire: Rust based package manager for macOS

#179
post #170
post #26

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

> probably settle for automatic build system detection based on archive structure there Please add knobs for the end user to manually configure this per package and global default before adding autodetection. As a user to is very frustrating to have to patch the package manager to override some well-intentioned automagic which didn't consider my setup or dig through sources to uncover some undocumented assumption. ya…

I'll add manual override flags and also let users not only build from source from formulae but any dir on their machine they want, only makes sense

Re: Sapphire: Rust based package manager for macOS

#180

Earlier quoted context omitted.

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…

oh, I guess this is why the nix installer creates 32 macOS users called _nixbld$N

It's explained in the documentation.

https://nix.dev/manual/nix/2.25/installation/multi-user

Post reply on HN