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

261–270 of 311 posts

Re: Sapphire: Rust based package manager for macOS

#261

Post by woodruffw »

IshKebab wrote: post #243
SonOfLilit wrote: post #241

Earlier quoted context omitted.

When I asked a few years ago, the brew maintainer said "parallelizing at this scale would hurt github, source: I work for github"

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

Re: Sapphire: Rust based package manager for macOS

#262

Post by maartn »

selkin wrote: post #148
maartn wrote: post #144

Please give it an easier command name than ‘sapphire’ if you want to win people over to use it. Double in size and three times as hard to remember (or type) than ‘brew’. Even cli peeps are still just people

https://en.wikipedia.org/wiki/Alias_(command)

Yeah, sure, bury UX tips in "also possible workarounds"

Re: Sapphire: Rust based package manager for macOS

#263

Post by exabrial »

I used to donate to the Homebrew project and actually liked it, until it's enshitification a few years ago.

* excessive superflurious animations? hell yeah

* emojis everywhere? of course!

* forced updates on by default

* breaking updates? thanks your problem noob. Try to keep up.

* versioning? lol, this isn't NASA

* backwards compatibility? Lol. come on, we redesigned the standard, the right way, the 5th time this time.

Its easy to criticize open source when you're not contributing, but thats why I sent my dollars over there, as I couldn't donate my time. Frustrating.

Re: Sapphire: Rust based package manager for macOS

#264

Post by woodruffw »

godelski wrote: post #254
Kwpolska wrote: post #237

Earlier quoted context omitted.

You should only be using Homebrew for installing software that happens to be written in Python, not dependencies for your own Python projects. If you do that, the Python version does not matter, it's just whatever version is required to make the package work.

> not dependencies for your own Python projects I'm not doing that. Honestly I'm not sure how to do that and it sounds like a real pain. > the Python version does not matter This is incorrect. Go check what versions of Python brew has installed for you. It's definitely not your system version... It's not "what works" it is "what the maintainer specified". And according to the brew devs this is supposed to be /the lat…

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 `pyenv` as well: `uv` handles multiple interpreters transparently, so you may not even realize how many you have installed. I think this is a good pattern: disk space is cheap relative to the timesink of connecting the right Python version to the right set of packages, which is why every distribution scheme (including both Homebrew and Debian) prefers to distribute multiple Python versions.

Re: Sapphire: Rust based package manager for macOS

#266

Post by chuckadams »

Philpax wrote: post #197
Lammy wrote: post #125

Earlier quoted context omitted.

That one was non-obvious to me as well, but I am sympathetic to the need to call them something . Not trying to bikeshed, but if there was a single obvious name for them then you would have used it instead of “DMG or PKG or something”.

Certainly, but I'm sure there's a more descriptive name than "cask"!

The nice thing about new terms is they don’t have overlapping meanings with existing ones. And FFS why do people want to suck the joy and frivolity out of everything?

Re: Sapphire: Rust based package manager for macOS

#268

Post by larusso »

tannhaeuser wrote: post #228
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…

Any idea what's up with MacPorts lately? Packages I needed to install were uncharacteristically broken or out of date which wasn't a thing ever since I switched from Fink ages ago. Apple used to use MacPorts internally and put resources into but they stopped doing so?

Didn‘t use it for quite some time now. I actually switched to nix packages for a while and was happy. Even worked in tandem with brew but I had a glibc issue on my shared Linux setup I could not resolve. I‘m still on nixos on Linux and tested nix on macOS again with flakes. I‘m not there yet to fully commit though.

Re: Sapphire: Rust based package manager for macOS

#269

Post by SonOfLilit »

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

(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")
Post reply on HN