Sapphire: Rust based package manager for macOS • Hacker News Board

Re: Sapphire: Rust based package manager for macOS

#301

Post by SonOfLilit » Thu, Apr 24, 2025, 5:24 AM UTC

woodruffw wrote: post #277

SonOfLilit wrote: post #269

Earlier quoted context omitted.

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

I agree that the brew devs are not stupid or lazy (as can be seen by the great popularity of the tool they developed among the complaining demographic).

I suspect they are wrong in this specific care based on the "every other package manager solved this" heuristic, but I have no doubt this is not a straightforward issue.

Personally, I dropped the case after offering to send a PR and getting back a "we won't accept this, it's not because we didn't think of it, from where we're standing it's a bad idea". They may or may not be wrong, but X am definitely wrong here, knowing almost nothing about it.

Re: Sapphire: Rust based package manager for macOS

#302

Post by fnord123 » Thu, Apr 24, 2025, 7:39 AM UTC

jrochkind1 wrote: post #29

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…

What makes you interested in a rust implementation of brew? I'm guessing it's that you hoping that it is eventually more performant -- are there specific areas of current brew you have identified as performance bottlenecks likely to eventually benefit from a rust implementation? Or any more info to share about assumptions/hopes that motivated this or any other motivations?

`brew search python` takes 3 seconds from a cold start.

Re: Sapphire: Rust based package manager for macOS

#303

Post by fnord123 » Thu, Apr 24, 2025, 7:42 AM UTC

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…

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

cmon, `brew cleanup --prune=0` is just part of the muscle memory by now.

Re: Sapphire: Rust based package manager for macOS

#304

Post by MelodyUwU » Thu, Apr 24, 2025, 12:36 PM UTC

a-french-anon wrote: post #247

MelodyUwU wrote: post #242

still, nothing can replace macports for me, ever

I use Macports on my work Macbook, but I'd love for Portage prefix to be fully functional on ARM Mac, personally. The tool interface is just so much better.

on contrast, I have a 32bit macbook pro on snow leopard, so none of these shiny tools can be even remotely useful to me (sapphire being arm only? yeah, that)

Re: Sapphire: Rust based package manager for macOS

#305

Post by okcdz » Fri, Apr 25, 2025, 6:43 AM UTC

Sounds good. But what are the advantages of implementing a package manager in Rust? I'd think languages with dynamic features would be more extensible and easier to iterate on.

Re: Sapphire: Rust based package manager for macOS

#306

Post by kusokurae » Fri, Apr 25, 2025, 3:38 PM UTC

mdaniel wrote: post #218

woodruffw wrote: post #214

Earlier quoted context omitted.

I completely agree. I think Ruby has actually been a pretty great boon of a language choice because of the formula DSL, but that goes back to the DX point and not something fundamental to the language.

Merely for your consideration, Ruby is great if you live in that codebase all the time, but Ruby -- in general, not just Homebrew -- has indescribably bad discoverability. I mean that both in terms of "what can I write where my cursor is?" and its friend "where the hell did this symbol under my cursor come from?" I'm acutely aware someone's going to say LSP something or Rubymine something else but as for drive-by con…

I've tried to love Ruby and use it daily for money, but by far the best justifications I have for the RoR dev experience are: it keeps me employed, and it's great if you're the one who wrote everything.

Re: Sapphire: Rust based package manager for macOS

#307

Post by tekknik » Fri, Apr 25, 2025, 3:44 PM UTC

mort96 wrote: post #74

bartvk wrote: post #70

Earlier quoted context omitted.

Nowadays, normal users don't need to know. They just "brew install ".

I disagree. I need to understand what Homebrew means when it says that a cask is keg-only or whatever, or what it means to tap a cellar or whatever when I wanna add repositories. The documentation and '--help' output also refers to the beer brewing terms, not standard package management terms.

I always found terminology like this refreshing. You don’t need to know it for 99% of interactions and really only need to know it if you’re building formulae. But what’s with all the engineers complaining because someone made a fun project? Why does everything have to be tediously serious?

Re: Sapphire: Rust based package manager for macOS

#308

Post by ycombinatrix » Sat, Apr 26, 2025, 12:43 AM UTC

godelski wrote: post #288

woodruffw wrote: post #264

Earlier quoted context omitted.

I don't follow the argument here: * One of the main reasons Homebrew doesn't use the "system" Python is because Apple has repeatedly indicated that they want to remove it, and that integrators should not depend on it. This, plus per-package Python version requirements makes using a single system Python a non-starter. * The "bloat" you're noting in Homebrew around multiple Python interpreters is present in `uv` and `p…

> because Apple has repeatedly indicated that they want to remove it That's not a reason to not use it. There's absolutely zero reason for me to have two copies of an exact same Python version (e.g 3.11.4). There is rarely reason to have a differing subversions (3.11.3 vs 3.11.4). > is present in `uv` Are you guessing or do you know? Try it out. Prove me wrong. I said they search for versions on your system and link…

Why should brew handle 3.11.3 differently from 3.11.4, just because you have another copy of it on your computer? What if apple patches it or updates the version suddenly?

That kind of magical special case behavior is not intuitive and creates more problems than it is worth.

Re: Sapphire: Rust based package manager for macOS

#309

Post by EasyMark » Sat, Apr 26, 2025, 4:39 PM UTC

fastball wrote: post #208

woodruffw wrote: post #54

With my Homebrew hat on, but not speaking for others: I think this is pretty cool, and demonstrates something that we've discussed indirectly for years. At its core, there are really two parts to Homebrew: 1. There's the client side, i.e. `brew`, which 99.9% of users stick to happy paths (bottle installs, supported platforms) within. These users could be supported with relative ease by a small native-code installer,…

Yeah, to me the language (ruby) has nothing to do with the success of Homebrew, it is entirely about the DX around backend packaging. The main reason I switched from MacPorts to Homebrew back in the day is because when a new version of [insert software here] was released, I could expect the brew package to be updated within days. MacPorts always lagged significantly behind, and oftentimes didn't have certain packages…

I kept hearing how great macports was with “separation from the system” and being more unixy and tried it two times. Both times it ended up borked. To their credit, it is very easy to uninstall (but not “one task” as it should be). I have never broken brew. I mean I've had packages not work, but the systems itself never got broken because of libraries or broken installs, I could always back out a broken package easily.

I can't remember the last time my "brewup" alias failed me

brew update && brew upgrade -g -f && brew cleanup --prune=all

Re: Sapphire: Rust based package manager for macOS

#310

Post by cstrahan » Sun, Apr 27, 2025, 12:07 AM UTC

user82747493 wrote: post #64

cstrahan wrote: post #39

Earlier quoted context omitted.

> It’s also open source, did they not accept your pull requests for these “improvements”? I don’t think you are being fair. This question presupposes that the supposed problems can be solved by iterative changes, rather than being inherent in the chosen design/architecture of the software, which usually requires complete replacement thereof (as well as the leadership thereof, as people who choose poor solutions to pr…

Then fork it! Make a new or better one! Handwaving it’s not good does nothing for anyone

People share negative sentiments for a number of reasons. Sometimes it’s emotionally motivated (like venting), sometimes it’s because you want to see less hype and more realistic discourse are about the deficiencies in our industry. There simply isn’t enough time to fix all the things that are problematic or completely broken, so naturally some things are only going to be talked about, rather than worked on.

And, I’ll point out the irony in your directive: you take issue with people expressing criticism without taking action to completely resolve the respective issue, and then you come along to express criticism by tell people to not complain but instead offer up free labor, when you could go and solve the problem that resulted in the original complaint.