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

151–160 of 311 posts

Re: Sapphire: Rust based package manager for macOS

#151

Post by woodruffw »

frollogaston wrote: post #149
woodruffw wrote: post #143

Earlier quoted context omitted.

There are two things that work in `uv`'s favor (which, to be clear, is an incredible tool that I'm a big fan of): 1. Python packaging, unlike Homebrew, does have a compute-heavy phase in the form of dependency resolution. `uv` can make significant gains over `pip` in that phase. 2. `uv` performs parallel downloads and other operations, in part because of Rust's fearless parallelism. Homebrew doesn't really have (1),…

Python should be able to do parallel downloads at least, albeit having the overhead of multiple OS threads unless you're using asyncio.

Yep. The limitation in pip is architectural, not on Python's own side. However, there's been some progress there recently[1].

[1]: https://github.com/pypa/pip/issues/825

Re: Sapphire: Rust based package manager for macOS

#152

Post by Asraelite »

alexykn wrote: post #122
jdeaton wrote: post #120

Earlier quoted context omitted.

Yeah i vote it should be rebranded “why”

command: why install htop, -> install start: because you wan' it -> done: you got it Something like that you mean?

I would love if the way to respond "yes" to the CLI is "why not"

Re: Sapphire: Rust based package manager for macOS

#153

Post by woodruffw »

Lammy wrote: post #139
StopDisinfo910 wrote: post #104

Earlier quoted context omitted.

Just go read the original announcements of homebrew. They expend at length about how Macport was wrong for shipping its own tool chain and homebrew was somehow superior for reusing the one shipped with MacOS (guess how it turned out). The fact that most packages completely broke if installed outside of /usr/local (itself a non sensical default) was just cherry on the cake. And let’s not talk about how everything brok…

Found it because I was curious: https://github.com/Homebrew/legacy-homebrew/commit/29d85578e... Here are the comparisons to other package managers: > Packages are brewed in individual, versioned kegs. Then symlinks are created to give a normal POSIX tree. This way the filesystem is the package database. Everything else is now easy. We are made of win. vs MacPorts registry which used its own homebrewed (lol) Receipts…

From 2009, so before my involvement. I'll note that this also says a bunch of things that aren't true in current-day Homebrew (Casks, for example, are distributions of .app bundles), so I think it'd be accurate to say that it doesn't reflect the project's current (or even past-decade) views.

Re: Sapphire: Rust based package manager for macOS

#155

Post by watermelon0 »

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…

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.

Re: Sapphire: Rust based package manager for macOS

#156

Post by morning-coffee »

whywhywhywhy wrote: post #118

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.

Maybe `grog` (or `grug` from https://grugbrain.dev)? :)

Re: Sapphire: Rust based package manager for macOS

#157

Post by bhouston »

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.

You should only re-distribute the original file that was downloaded and thus one can just advertise the original torrent that was downloaded.

But as you said earlier, brew is a point in time command and this BitTorrent solution would only really work if brew switched to an always-on service. And I am not sure that many people want to do that, although I am sure some would.

Re: Sapphire: Rust based package manager for macOS

#159

Post by hackingonempty »

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…

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

Yes, brew exits when it is done installing, nothing would need to change about that if you used BT protocol to speed up downloads. I'm sure you do have some helpful users who would volunteer to seed their cache though, which would become feasible.

> That's not the challenge. The challenge is distributing those updates.

The metadata goes in the formula alongside the current metadata (URLs and hashes.)

Re: Sapphire: Rust based package manager for macOS

#160

Post by cfreksen »

syvolt wrote: post #134
alexykn wrote: post #121

Earlier quoted context omitted.

I know, probably will, also feel typing out sapphire for the command all the time is annoying + sapp would be weird. For me technical implementation comes first though. I'll do that when something comes to mind

'sph' doesn't seem too bad though.

This reminds me of the PIK image format (a precursor to JPEG XL) whose name happens to be a word for penis in some languages[0]. In the present case "SPH" is a kink/fetish term meaning "Small Penis Humiliation"[1]. I don't know how many people would think of that, though.

I am not sure if the lesson is to try harder to avoid offence, or live with the fact that words can have multiple meanings and we can be "professional" enough to ignore some of those meanings in some contexts.

[0]: https://github.com/google/pik/issues/6

[1]: https://www.urbandictionary.com/define.php?term=sph

Post reply on HN