Sapphire: Rust based package manager for macOS

Original Article ↗ Hacker News Discussion ↗

Scope and Goals of Sapphire

  • Sapphire is explicitly alpha and currently reuses Homebrew’s bottles and casks; it’s essentially a new CLI and installer on top of Homebrew’s infrastructure.
  • The author built it for personal use because Homebrew felt too slow and awkward to wrap for a planned declarative macOS “system manager.”
  • Near‑term focus: make bottle and cask installs fast and reliable; source builds are acknowledged as hard due to Homebrew’s Ruby DSL and incomplete JSON metadata.
  • Longer‑term: introduce a more machine‑readable packaging format (e.g. YAML/TOML/Lua‑based) and add declarative configuration, not to replace Homebrew’s repo but to sit atop it.
  • Several commenters ask for a clear “why”/rationale section and feature differentiation in the README.

Homebrew Strengths and Infrastructure

  • Many view Homebrew’s main win over MacPorts/Fink as UX/DX: easy formulas, Ruby DSL, GitHub workflow, rapid package updates via automated checks.
  • A maintainer explains there are two halves: the relatively simple client, and the large, complex backend (formula DSL, CI, automation) which is hard to “rewrite in Rust.”
  • Some note Homebrew has improved a lot in recent years (faster commands, less Ruby evaluation).

Homebrew Pain Points

  • Complaints: slow installs (serialized downloads/installs, auto‑updates), heavy animations/verbosity, cache bloat, difficulty debugging breakage.
  • Architectural grievances: no sudo by design, single shared prefix under one user, fragile with multi‑user setups, discouraging non‑standard prefixes and beta macOS installs.
  • Policy grievances: removal of build options/custom flags, opt‑out analytics, “rolling/unstable” feel vs Debian‑style stability.
  • Some employers ban Homebrew because it enables installing unvetted third‑party software.

Performance and Parallelism

  • Several argue Homebrew is mostly I/O‑bound; language choice matters less than parallel downloads and better scheduling.
  • A maintainer says parallel downloads are limited deliberately to avoid overloading GitHub and third‑party hosts; smaller projects can be more aggressive.
  • Long subthread debates P2P/Bittorrent and hybrid CDN approaches; consensus is that complexity and reliability concerns make this unattractive for a mass‑market client.

Language Choice and “Rewrite in Rust” Debate

  • Some celebrate a Rust implementation as inherently faster, safer, easier to distribute.
  • Others push back on “rewrite in Rust” as a shallow value proposition, especially when the core workload is downloads and unpacking.
  • Comparisons drawn to uv vs pip: big gains there came from better dependency resolution and parallelism, not Rust alone.

Compatibility, Alternatives, and Missing Features

  • Sapphire’s Homebrew compatibility (bottles/casks, same terminology) is seen as both a strength and a limitation; full independence would require a new packaging DSL and large porting effort.
  • Requests for differentiation include: easier universal binaries, per‑user installs, better multi‑user stories, pinning versions, and more declarative setups (some cite Brew Bundle, Nix, and home‑manager as inspiration).
  • Multiple commenters stick with or praise MacPorts, Nix, or other tools; some just want an apt-get‑like experience on macOS.

UX, Terminology, and Naming

  • Many dislike Homebrew’s beer metaphors (keg, cask, tap, bottle) and want standard terms like “package” and “repository.”
  • Others find whimsical terminology acceptable since most users only run brew install.
  • Sapphire’s command name is viewed as too long/hard to type; suggestions include shorter CLIs and separating project name from binary name. The author is open to renaming and later cleaning up terminology.