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

131–140 of 311 posts

Re: Sapphire: Rust based package manager for macOS

#131

Post by mort96 »

runjake wrote: post #61
hk1337 wrote: post #32

I wish homebrew was a little more friendly to installing in a directory other than what the installer sets. I used to have a lot of permissions issues back when /usr/local was the only directory and none since I started installing it in ~/.brew

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.

Re: Sapphire: Rust based package manager for macOS

#132

Post by dijit »

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 use it on my daily driver, and it's at least two-orders of magnitude slower than apt.

However, the speed increase coincided with my upgrade to an M-Series laptop, so it's possible I just presumed there was a significant hardware speedup in the time we're talking about.

Re: Sapphire: Rust based package manager for macOS

#134

Post by syvolt »

alexykn wrote: post #121
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.

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.

Re: Sapphire: Rust based package manager for macOS

#135

Post by frollogaston »

selkin wrote: post #127
frollogaston wrote: post #94

Earlier quoted context omitted.

I mainly disagree with the Homebrew stance on sudo/root. They claim it's better to install everything under a user dir, but 10% of the time that doesn't work for whatever reason, and tons of users have screwed up their permissions trying to fix it. No other package manager has this issue.

I am not too fond of this design for reasons of privilege separation and FHS-alignment, but can accept it as most Homebrew users don't have their Macintosh computers used by multiple people.

My machine is single-user, problem is some things require root. Maybe they shouldn't according to Homebrew's stance on permissions, but idk, I'm working with what I've got.

Re: Sapphire: Rust based package manager for macOS

#136

Post by selkin »

mort96 wrote: post #129
frollogaston wrote: post #94

Earlier quoted context omitted.

I mainly disagree with the Homebrew stance on sudo/root. They claim it's better to install everything under a user dir, but 10% of the time that doesn't work for whatever reason, and tons of users have screwed up their permissions trying to fix it. No other package manager has this issue.

I would've been alright if they actually installed stuff in a user dir under the user's home folder, but it's insane to have a system-wide /opt/homebrew owned by whatever user happened to run the installer. Very icky.

It is possible to install Homebrew itself and the software it packages under your home folder[0], though that configuration is not officially supported.

This is how I install Homebrew when I have to, and so far the only issue I ran into is that binary packages are often tagged as installable only to Homebrew's default folder, so Homebrew had to built the to-be-installed software from source instead, resulting in it taking longer and the computer fans spinning louder.

[0] https://docs.brew.sh/Installation#untar-anywhere-unsupported

Re: Sapphire: Rust based package manager for macOS

#137

Post by chrisweekly »

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,…

> "it's very hard to RIIR"

RIIR - "Rewrite It In Rust" (maybe obvious in context? sharing in case not)

Re: Sapphire: Rust based package manager for macOS

#138

Post by woodruffw »

Zambyte wrote: post #71
woodruffw wrote: post #57

Earlier quoted context omitted.

This has nothing to do with Homebrew. It's a different project.

Yeah, but the relationship makes my spidey senses tingle even if it's not accurate.

Consider re-attuning your spidey senses away from inaccurate things!

Re: Sapphire: Rust based package manager for macOS

#139

Post by Lammy »

StopDisinfo910 wrote: post #104
woodruffw wrote: post #41

Earlier quoted context omitted.

Who is "they"? I've never FUDed MacPorts, and in a decade of contributing to and maintaining Homebrew I can say honestly that I've never heard any other maintainer talk much about it beyond user experience. (Beyond anything else, Homebrew's biggest "win" over MacPorts was and probably is still UX and DX. The core technology of a packaging ecosystem is rarely itself the differentiator.)

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 files in 2009, and now uses a SQLite DB: https://guide.macports.org/chunked/internals.registry.html#i...

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

vs MacPorts installs to `/opt/local` as root.

> Why Not MacPorts?

> =================

> 1. MacPorts installs its own libz, its own openssl, etc. It is an autarky.

> This makes no sense to me. OS X comes with all that shit.

> 2. MacPorts support Tiger, and PPC. We don't, so things are better optimised.

There is no “Why Not Fink?” section.

And because I didn't know the word autarky: https://en.wiktionary.org/wiki/autarky

Re: Sapphire: Rust based package manager for macOS

#140

Post by [deleted] »

hackingonempty wrote: post #75
woodruffw wrote: post #63

Earlier quoted context omitted.

FWIW: a longstanding limitation for parallel downloads within Homebrew isn't architectural (it's not too hard to add!) but structural with respect to Homebrew's download sources: GitHub and others are very gracious with the amount of traffic we send their way, and we don't want to overtax services that have other major consuming parties. (This is a perverse countereffect: small projects can make performance decisions…

P2P protocols like BitTorrent are made for this kind of problem.

[deleted]
Post reply on HN