Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Sapphire: Rust based package manager for macOS

github.com

Post reply on HN
Print view View original

161–170 of 311 posts

Re: Sapphire: Rust based package manager for macOS

#161

Post by skydhash »

larusso wrote: 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…

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.

Re: Sapphire: Rust based package manager for macOS

#162

Post by [deleted] »

Scramblejams wrote: post #114
alexykn wrote: 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…

[deleted]

Re: Sapphire: Rust based package manager for macOS

#163

Post by Lammy »

woodruffw wrote: post #128
hackingonempty wrote: post #98

Earlier quoted context omitted.

I think you are misinformed as BitTorrent, for instance, is much more reliable than https alone. The reward scheme is built in already: the client uploads while it's downloading and installing and prioritizes the clients it is downloading from. At worst, the reliability and performance are the same as the web seed. Generating additional metadata at bottle build time doesn't appear to be much of a technical challenge…

> The reward scheme is built in already: the client uploads while it's downloading and installing and prioritizes the clients it is downloading from. These are asymmetric: brew runs at a point in time, and most people decidedly do not want brew running in the background or blocking while leechers are still being serviced. They want it to exit quickly once the task at hand is done. > Generating additional metadata at…

> 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://www.bittorrent.org/beps/bep_0046.html

If that updated torrent is a BEP-0052 (v2) torrent it will hash per-file, and so the updated v2 torrent will have identical hashes for files which aren't changed: https://www.bittorrent.org/beps/bep_0052.html

This combines with BEP-0038 so the updated torrent can refer to the infohash of the older torrent with which it shares files, so if you already have the old one you only have to download files that have changed: https://www.bittorrent.org/beps/bep_0038.html

Re: Sapphire: Rust based package manager for macOS

#165

Post by woodruffw »

Lammy wrote: post #163
woodruffw wrote: post #128

Earlier quoted context omitted.

> The reward scheme is built in already: the client uploads while it's downloading and installing and prioritizes the clients it is downloading from. These are asymmetric: brew runs at a point in time, and most people decidedly do not want brew running in the background or blocking while leechers are still being serviced. They want it to exit quickly once the task at hand is done. > Generating additional metadata at…

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

Re: Sapphire: Rust based package manager for macOS

#166

Post by kergonath »

mort96 wrote: post #123
ok_computer wrote: post #115

Earlier quoted context omitted.

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.

It's actually one of the main reasons I landed on using Axum for a web server in Rust instead of Rocket: I got fed up with the additional level of semantic indirection the cutesy names added. I didn't wanna burn brain cycles decoding what it means to install fairings or launch rockets, or what "ignition" means contra "liftoff". I like boring names for things.

> I like boring names for things.

It’s not that I like boring. But I really like descriptive names. I have other things to do with my time than figuring out what the hell a cask, a tap, or a bottle is. Like solving the problem that requires the damn software.

Re: Sapphire: Rust based package manager for macOS

#167

Post by runjake »

mort96 wrote: post #131
runjake wrote: post #61

Earlier quoted context omitted.

For the last 5 years (since Apple Silicon was released), Homebrew has installed to /opt/homebrew by default.

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

Re: Sapphire: Rust based package manager for macOS

#168

Post by mrbonner »

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.

Re: Sapphire: Rust based package manager for macOS

#169

Post by scribu »

watermelon0 wrote: post #155
Scramblejams wrote: post #114

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…

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.

Re: Sapphire: Rust based package manager for macOS

#170

Post by 3np »

alexykn wrote: 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. yarn is a cautionary example.

Post reply on HN