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

211–220 of 311 posts

Re: Sapphire: Rust based package manager for macOS

#211

Post by KolenCh »

xiphias2 wrote: post #126
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 not _just_ the infrastructure that is awesome for homebrew. The help I got from the team, answering in real-time when I didn't know how to get through the CI bugs is amazing. It's the boring maintainence work that makes it so special for me. I also feel that there could be a lot of automation in the backend part, catching bugs early (maybe even on local machine before CI run) for example.

I think you mean “the hell I got from the team”.

I wonder if anything changed substantially over the years to make you say that?

Re: Sapphire: Rust based package manager for macOS

#212

Post by p_ing »

QuercusMax wrote: post #100
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.

As an experienced homebrewer, I don't think knowing about making beer makes it any clearer to me. Why do I need to install Docker from a Cask? Oh, it's because on Mac, a Cask is actually a Mac package (DMG or PKG or something). It's just arbitrary beer-flavored terminology. No different than the Windows registry, which apparently uses a honeybee / hive metaphor because some Windows dev hated bees and their teammates…

A HIVE is the only nonsensical name in the registry; everything else is keys, subkeys, or values.

https://learn.microsoft.com/en-us/windows/win32/sysinfo/stru...

That said, the registry has been around for ~30 years and the terminology is well known to Windows users. It didn't build off of previously available terminology.

Homebrew just made shit up on the spot based on the project's name to be internally consistent with itself.

Microsoft has it's own fsckery of randomly named cute crap elsewhere, of course.

Re: Sapphire: Rust based package manager for macOS

#213

Post by woodruffw »

WD-42 wrote: post #187
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…

Another performance characteristic that used to piss me off when I used brew was that at least for one program, it had to invoke brew to launch. Something about finding a path. So that's an entire ruby interpreter starting and stopping just to (in this case) run a bash script. Horribly slow.

That’s been fixed for at least a year! But yes, that used to be very slow, particularly when loading brew also meant loading every formula.

Re: Sapphire: Rust based package manager for macOS

#214

Post by woodruffw »

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

Re: Sapphire: Rust based package manager for macOS

#215

Post by stevage »

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…

Does the "casks" and "bottles" language imply that it's intended be compatible with Homebrew? That isn't made explicit in the description.

Re: Sapphire: Rust based package manager for macOS

#216

Post by godelski »

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…

This is awesome!

Is there uv support?[0]

One of my biggest gripes about brew is how they manage dependencies. The devs have a conflicting philosophy that creates bloat. Package maintainers must define settings, settings should always use the latest Python version. It makes no sense. Maintainers won't update unless things break so you got a bunch of Python versions running around. And it won't use system Python!

Uv seems to provide an elegant solution for this. You can build a venv for each package and rust version will only have the specified deps. Since uv finds all your Python instances (and packages) and soft links them you have way less bloat and venvs become really useful. You can also use run and other tools to handle executables

Plus is also rust so good synergy ;)

[0] https://astral.sh/blog/uv

Re: Sapphire: Rust based package manager for macOS

#217

Post by mdaniel »

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…

As best I can tell, that's partially due to the size of the community, but also because Homebrew went out of their way to teach the system to fish via the 3(?) different kinds of "check for updates" built into the Formulae:

- GitHub release sniffing https://github.com/Homebrew/homebrew-core/blob/b331b99b9f24f...

- page scraping https://github.com/Homebrew/homebrew-core/blob/b331b99b9f24f... (and also per-content-type flavors json and presumably xml)

- links to other formulae (IOW cascading updates): https://github.com/Homebrew/homebrew-core/blob/b331b99b9f24f...

and then the $(brew livecheck) invocation which will do a subset, a curated list, or hypothetically all of them

I can't imagine why MacPorts or our new Sapphire friend couldn't adopt a similar strategy

Re: Sapphire: Rust based package manager for macOS

#218

Post by mdaniel »

woodruffw wrote: post #214
fastball wrote: post #208

Earlier quoted context omitted.

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 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 contributions, ... anyway, like I said, just for your consideration

Re: Sapphire: Rust based package manager for macOS

#219

Post by fastball »

mdaniel wrote: post #217
fastball wrote: post #208

Earlier quoted context omitted.

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…

As best I can tell, that's partially due to the size of the community, but also because Homebrew went out of their way to teach the system to fish via the 3(?) different kinds of "check for updates" built into the Formulae: - GitHub release sniffing https://github.com/Homebrew/homebrew-core/blob/b331b99b9f24f... - page scraping https://github.com/Homebrew/homebrew-core/blob/b331b99b9f24f... (and also per-content-type…

When Homebrew started (and when I switched) the community was significantly smaller than MacPorts. It is due to the system you mention (and the community that this MX in turn cultivated) that allowed brew to dominate the mac packaging market.

Absolutely MacPorts and Sapphire can adopt the same strategy, but the point is that brew already has, so what exactly would the benefit be? e.g. if the language of choice is effectively meaningless, re-writing homebrew in Rust serves effectively no purpose. This is contrasted with systems and software where the performance or correctness is the most important feature, and therefore RIIR can be a big win.

Said another way: Brew was not "re-write MacPorts in Ruby", it had much loftier goals which it then executed on effectively. Sapphire mostly seems to be "re-write Brew in Rust", without much beyond that. So the only real gain is a bit more performance out of the CLI.

Post reply on HN