Sapphire: Rust-basierter Paketmanager für macOS (Homebrew-Alternative)

• Sapphire ist ein Paketmanager der nächsten Generation, entwickelt in Rust
• Er ist von Homebrew inspiriert und installiert und verwaltet Formulae und Casks
• Derzeit wird nur die ARM-Architektur unterstützt; x86 könnte künftig ergänzt werden
• Das Projekt besteht aus sapphire-core und sapphire-cli
• Sapphire steht unter der BSD-3-Clause-Lizenz

---

Warnung

• Sapphire ist experimentelle Software in aktiver Entwicklung und kann instabil sein
• Wenn mit brew installierte Casks mit Sapphire neu installiert werden, werden sie in leicht abweichenden Pfaden installiert, und Benutzereinstellungen werden nicht automatisch migriert

⚙️ Projektstruktur

• sapphire-core: Kernbibliothek, zuständig für das Abrufen von Paketen, das Auflösen von Abhängigkeiten, das Entpacken von Archiven und die Verarbeitung von Artefakten
• sapphire-cli: Kommandozeilenoberfläche; die ausführbare Datei sapphire kapselt die Kernbibliothek

🚀 Roadmap

1. Aktualisierung installierter Pakete mit dem Befehl upgrade
2. Bereinigung alter Downloads, Versionen und Caches
3. Befehl Reinstall für schnelle Neuinstallationen
4. Prefix isolation mit Unterstützung für /opt/sapphire als eigenständiges Layout
5. Helfer sapphire init zum Bootstrapping der Umgebung
6. Fortlaufende Bugfixes und Verbesserungen der Stabilität

📦 Verwendung

• Hilfe anzeigen: sapphire --help
• Metadaten aktualisieren: sapphire update
• Nach Paketen suchen: sapphire search
• Paketinformationen abrufen: sapphire info
• Bottle oder Cask installieren: sapphire install
• Formula aus dem Quellcode bauen und installieren: sapphire install --build-from-source
• Deinstallieren: sapphire uninstall
• (demnächst verfügbar) sapphire upgrade [--all] , sapphire cleanup, sapphire init

🏗️ Aus dem Quellcode bauen

Voraussetzung: stabile Rust-Toolchain

• git clone
• cd sapphire
• cargo build --release
• Die Binärdatei sapphire befindet sich unter target/release/sapphire; diesen Pfad zu PATH hinzufügen

[GN⁺]

Hacker-News-Kommentare

• Er erklärt, dass sein selbst entwickeltes Projekt Homebrew in vielerlei Hinsicht nicht überlegen sei, aber einige Probleme wie die Konfiguration relativer Pfade löse

  • Die Installation der meisten Bottles funktioniert gut, mit Ausnahme von Rust
  • Formeln aus dem Quellcode zu bauen ist wegen unzureichender Informationen in der JSON-API schwierig
  • Er plant, .rb-Skripte in ein allgemeineres maschinenlesbares Format umzuwandeln
  • Die Umwandlung von .dmg nach .app und .pkg-Installer funktionieren in Tests gut
  • Da die meisten Formeln auf modernen ARM-Macs als Bottles bereitgestellt werden, könnte es ein vollwertiger Paketmanager sein
  • Weil sich Ansible für eine einzelne Maschine überdimensioniert anfühlte, entwickelt er einen deklarativen Paket- und Systemmanager für den Mac
  • Das Wrappen von Brew-Befehlen war zu langsam, was ihn dazu brachte, ein neues Projekt zu starten
  • Er bedankt sich für Bugreports, Issues und konstruktive Pull Requests

• Er erläutert zwei Kernbestandteile von Homebrew

  • Auf der Client-Seite nutzen die meisten Anwender Bottle-Installationen und unterstützte Plattformen, was sich leicht mit einem kleinen nativen Code-Installer unterstützen lässt
  • Entwickler, Repositories und CI/CD-Maschinen bilden die komplexe Infrastruktur von Homebrew, die eng mit der Formula-DSL verbunden ist
  • Homebrew isoliert die Client-Seite gut von der komplexen Infrastruktur
  • Parallele Downloads von Bottles und DMGs sind keine architektonische Beschränkung von Homebrew, sondern eine bewusste Entscheidung aus Rücksicht auf die Dienste

• Das Projekt wird als unterhaltsam und gut gemacht bewertet

  • Die Beibehaltung der Homebrew-Terminologie wird kritisch gesehen
  • Es wird vorgeschlagen, stattdessen Standardbegriffe wie Pakete und Repositories zu verwenden

• Das Ziel einer Gleichwertigkeit mit Homebrew wird infrage gestellt

  • Zusätzliche Funktionen wie Version-Pinning werden vorgeschlagen

• Jemand war früher MacPorts-Nutzer, erklärt aber, warum er zu Homebrew gewechselt ist

  • Er glaubt nicht, dass ein neuer Paketmanager automatisch zu einer besseren Konfiguration führt

• Es wird vorgeschlagen, im README Ziele, Motivation und Gründe zu ergänzen

  • Es müsse klarer erklärt werden, warum die Probleme von Homebrew gelöst werden sollen

• Das Verbesserungspotenzial von Homebrew wird anerkannt, und neue Versuche werden begrüßt

  • Zugleich wird Unzufriedenheit mit den Absichten und der Denkweise von Homebrew-Entwicklern und Paketierern geäußert

• Es wird vorgeschlagen, den Projektnamen zu verkürzen

  • Ein kurzer Name könnte einprägsamer sein und einen leichteren Eindruck vermitteln

• Es wird argumentiert, dass eine komplette Neuschreibung der Software nicht effektiv sei

  • Es wird vorgeschlagen, die Komponenten von Homebrew schrittweise zu ersetzen
  • Der Name Homebrew habe in der Hacker-Community kulturelle Bedeutung