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

271–280 of 311 posts

Re: Sapphire: Rust based package manager for macOS

#271

Post by pvg »

azinman2 wrote: post #112
runjake wrote: post #67

Earlier quoted context omitted.

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.

Doesn’t tell me how it differs

Not everything on HN has to come with a dissection and explanatory note - that's kind of the point of curiosity.

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.

Those are totally fine on HN too.

Re: Sapphire: Rust based package manager for macOS

#272

Post by azinman2 »

pvg wrote: post #271
azinman2 wrote: post #112

Earlier quoted context omitted.

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

Doesn’t tell me how it differs Not everything on HN has to come with a dissection and explanatory note - that's kind of the point of curiosity. 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. Those are totally fine on HN too.

Except the title (previously) said homebrew replacement. So when it doesn’t say why/what, and there’s no context, people are going to be confused.

Re: Sapphire: Rust based package manager for macOS

#273

Post by KennyBlanken »

woodruffw wrote: post #60
dijit wrote: post #56

Earlier quoted context omitted.

I say this from ignorance, but coming from a lineage of linux package managers; brew must be doing something wrong - and upon immediate introspection I doubt that its language specific. The performance of apt/dnf in comparison is surreal; but dnf (or at least yum, its predecessor) is written in Python; which has even worse performance characteristics than Ruby. Clearly something is wrong, I wonder how different they…

Have you tried Homebrew in the last year or so? I think a lot of people have an impression of Homebrew's performance from the "bad old days," i.e. back when Homebrew had to evaluate every single local formula file to perform any operations at all. (There's still low handing fruit, but it's not like it was a few years ago where `brew list` took seconds to run. It now runs nearly instantaneously for me locally, like mo…

Yes, I have. It's slow as shit even on an M1. In the time it takes to install one brew package on an M1, a sudo apt update && sudo apt dist-upgrade has finished updating a dozen packages on a ten year old intel system with a SATA SSD.

I fucking hate homebrew.

I hate the fact that the project still has the attitude of "sudo is le hard and we are le tired."

The project people are assholes.

The maintainers are often well behind current releases.

It maintains a cache of every installed version for no good reason wasting ~10GB or more of my SSD space.

When it breaks it's impenetrable trying to figure out how it broke, there's nobody to ask for help, the documentation sucks, and the fastest thing is just to wipe the whole fucking directory and start over.

I could go on. I don't know a single person that likes using homebrew - it's just the package manager everyone resigned themselves to use.

Re: Sapphire: Rust based package manager for macOS

#274

Post by frollogaston »

agos wrote: post #249
frollogaston wrote: post #145

Earlier quoted context omitted.

The symptom was something like https://stackoverflow.com/questions/16432071/how-to-fix-home... , which btw has a terrible accepted answer. I forget the root cause (no pun intended), possibly some bad interaction with stuff I installed outside of Homebrew. It's also possible I did something wrong, but even then there's something to be said about so many users having the same problem uniquely with Homebrew. Lemme try t…

this kind of errors are quite common with Homebrew in my experience. if you did anything "wrong", then it's something really easy to do wrong which lots of other (me included) have done wrong at some point, and that the software should help to prevent

Digging through it more, it seems like Homebrew didn't play nice with anything else that used that dir. Maybe it's less of a problem now that it installs to /opt/homebrew, but I imagine there are still times Homebrew needs to place files in root-owned dirs or next to them.

This issue is also brought up in the Github commit posted here: https://news.ycombinator.com/item?id=43766371 "I wouldn't worry about it not being root. We don't install anything base enough for it to be a concern (unlike MacPorts or Fink)."

Re: Sapphire: Rust based package manager for macOS

#275

Post by AlphaSite »

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…

Can you just shell out to homebrew for unsupported cases? I don’t imagine the overhead of ruby will be that high compared to compiling the code.

Re: Sapphire: Rust based package manager for macOS

#276

Post by woodruffw »

KennyBlanken wrote: post #273
woodruffw wrote: post #60

Earlier quoted context omitted.

Have you tried Homebrew in the last year or so? I think a lot of people have an impression of Homebrew's performance from the "bad old days," i.e. back when Homebrew had to evaluate every single local formula file to perform any operations at all. (There's still low handing fruit, but it's not like it was a few years ago where `brew list` took seconds to run. It now runs nearly instantaneously for me locally, like mo…

Yes, I have. It's slow as shit even on an M1. In the time it takes to install one brew package on an M1, a sudo apt update && sudo apt dist-upgrade has finished updating a dozen packages on a ten year old intel system with a SATA SSD. I fucking hate homebrew. I hate the fact that the project still has the attitude of "sudo is le hard and we are le tired." The project people are assholes. The maintainers are often wel…

> I fucking hate homebrew.

> I hate the fact that the project still has the attitude of "sudo is le hard and we are le tired."

> The project people are assholes.

Have you considered that approaching us like this isn't productive and doesn't make anyone remotely interested in helping you?

Re: Sapphire: Rust based package manager for macOS

#277

Post by woodruffw »

SonOfLilit wrote: post #269
woodruffw wrote: post #261

Earlier quoted context omitted.

Can you think of any more charitable reason than this? I think it beggars belief that Homebrew isn’t interested in improving performance; it’s something we talk about constantly and is one of our largest and most consistent user asks. (It’s not just midnight, or terminals, as mentioned, not that either of these is really a “just”. And it’s not just GitHub, as mentioned.)

(In this subthread it is just github because we were discussing enabling parallelism for github only. The terminal proposal meant "keep it single thread for CI")

Okay. The problem is still present in the GH case, although to a lesser extent.

These kinds of complications on a "same experience for everyone" flow are also nontrivial: single-threading on CI is hard to explain to users who see very fast local installs and slow CI installs - the latter costs them extra money! - and complicates the story with mirrors, download groups that include non-GH origins, etc.

That's not to say it's impossible; as linked in another thread, it's something that's being actively worked on. But I think it should be understandable why "just parallelize it and you're wrong/stupid/lazy because you haven't already" is neither a contextualized or charitable response.

Re: Sapphire: Rust based package manager for macOS

#279

Post by philsnow »

ok_computer wrote: post #115
mort96 wrote: 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.

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.

Löve (lua thing for graphics / games) historically had this but the names were all sex-related (SECS, LUBE, COCK, AnAl, HUMP, Polygamy, Swingers, Quickie). None of the project names were metaphorically related to their functions.

It's toned down lately and a ton of projects have been renamed, though not scrubbed, so the old names are still in the code and some documentation uses the old names. Also, you can't rewrite tens of thousands of forum posts from 2010 that use the older names that show up while searching for issues.

Re: Sapphire: Rust based package manager for macOS

#280

Post by IshKebab »

woodruffw wrote: post #261
IshKebab wrote: post #243

Earlier quoted context omitted.

Definitely sounds like one of those "I don't want to do it because it's work, but I don't want to admit that so here's a spurious technical reason" excuses to me. If spikes at midnight etc are an issue just automatically disabled parallel downloads around midnight. Or only use them when running in a terminal. I really doubt it is an issue for GitHub though.

Can you think of any more charitable reason than this? I think it beggars belief that Homebrew isn’t interested in improving performance; it’s something we talk about constantly and is one of our largest and most consistent user asks. (It’s not just midnight, or terminals, as mentioned, not that either of these is really a “just”. And it’s not just GitHub, as mentioned.)

To be clear I think "it's a lot of work and we don't want to deal with the complexity" is a totally valid reason. I have that reason for not doing a ton of things.

I just don't think "it shouldn't be done" is really the true reason. It's very tempting to say that though because it sounds like a stronger defense than "I don't want to". I think some people that do it don't even realise.

Post reply on HN