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

201–210 of 311 posts

Re: Sapphire: Rust based package manager for macOS

#201

Post by [deleted] »

chrisweekly wrote: post #137
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)

[deleted]

Re: Sapphire: Rust based package manager for macOS

#203

Post by kccqzy »

selkin wrote: post #76

Homebrew sure has room for improvement, as most software does, and I appreciate every effort to replace and renew what we have with something better. But my own grievances with Homebrew isn't with the codebase itself. What discourages me from using Homebrew is the intent and the mindset of its developers and packagers, who, I think, see their goal building an "unstable" distribution, as Debian defines it: "[a distrib…

There are rolling distros on Linux that are remarkably stable. My current Linux distribution openSUSE Tumbleweed is one. And on macOS you already have an immutable system partition that provides a stable base to build on top of, so I fail to see the value proposition of a package manager on macOS that's deliberately slow.

Re: Sapphire: Rust based package manager for macOS

#204

Post by hk1337 »

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.

I don’t want it there either. The install script is defines the install directory without anyway to override it. It sets it to /usr/local or /opt/homebrew depending on the result of uname command.

I like it in ~/.brew where I have full permission to it and only my user.

Re: Sapphire: Rust based package manager for macOS

#205

Post by frollogaston »

no_wizard wrote: post #176
benatkin wrote: post #19

Earlier quoted context omitted.

if you see the issue I linked, there are a lot of thumbs up / thumbs down in the comments, it's not just me =)

I think I lack context enough that even the link doesn't make it very clear to me.

mxcl is the owner of this other project and also the original creator of Homebrew. Someone asked politely to remove a broken package from the list, mxcl gave an oddly combative response, then you see the rest.

Re: Sapphire: Rust based package manager for macOS

#206

Post by ks2048 »

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.

I agreee with this, but is there a “standard” of terms? “repo” I understand to be a git repo, with all it entails. But, “package”, “library”, “module”? It seems like different languages have differenct usages.

Re: Sapphire: Rust based package manager for macOS

#207

Post by koakuma-chan »

azinman2 wrote: post #116
IshKebab wrote: post #92

Earlier quoted context omitted.

Is it really necessary to restate the advantages of rewriting in Rust in every such project? Compared to Ruby programs Rust programs are faster, more robust, more maintainable, and easier to install. That's pretty much the same for any Rust rewrite (e.g. uv). It would be interesting to know if there are other goals though, e.g. UX improvements.

The speed of homebrew has never been limiting factor (for me). I think there are far more important factors in what’s maintainable or not than language, and homebrew is very easy to install. There has to be more important reasons to replace a mature widely use project like homebrew.

The issue with homebrew is not the programming language. The issue is homebrew itself. It takes forever to install packages, auto-updates without prompting you, etc. Also on my Mac it's been broken for years. It tries to auto-update and gets stuck forever.

https://github.com/orgs/Homebrew/discussions/1177

Re: Sapphire: Rust based package manager for macOS

#208

Post by fastball »

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

Re: Sapphire: Rust based package manager for macOS

#209

Post by wolrah »

IshKebab wrote: post #92
motorest wrote: post #45

Earlier quoted context omitted.

> It’s a real disservice to the project not to give a raison d’etre in the readme, or any kind of technical motivation / differences. This. There's a wave of projects whose only value proposition is this vacuous "let's reinvent the wheel in Rust" sales pitch, where nothing of value is proposed beyond throwing around the Rust buzzword.

Is it really necessary to restate the advantages of rewriting in Rust in every such project? Compared to Ruby programs Rust programs are faster, more robust, more maintainable, and easier to install. That's pretty much the same for any Rust rewrite (e.g. uv). It would be interesting to know if there are other goals though, e.g. UX improvements.

> Is it really necessary to restate the advantages of rewriting in Rust in every such project?

I'm with you when the "source" project is C/C++ or something in that realm, but when we're coming from an already memory-safe language I do think some sort of explanation is helpful. I see Homebrew as more of a "glue" application where its own performance isn't exactly critical as it coordinates processes that are much slower so I don't really care if it's a bit faster.

Re: Sapphire: Rust based package manager for macOS

#210

Post by akdev1l »

scribu wrote: post #169
watermelon0 wrote: post #155

Earlier quoted context omitted.

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.

You could run the build process with chroot or inside Docker, so that the hardcoded paths actually resolve to a designated subdirectory.

In many cases the build output also has hardcoded paths unfortunately

so doing `brew install` inside a container with the proper volumes it’s not sufficient to fix the issue. Everything would have to run from within the container as well.

Post reply on HN