Sapphire: administrador de paquetes para macOS basado en Rust (alternativa a Homebrew)

• Sapphire es un administrador de paquetes de próxima generación desarrollado en Rust
• Inspirado en Homebrew, instala y gestiona Formulae y Casks
• Actualmente solo es compatible con la arquitectura ARM; es posible que el soporte para x86 se agregue más adelante
• El proyecto está compuesto por sapphire-core y sapphire-cli
• Sapphire se distribuye bajo la licencia BSD-3-Clause

---

Advertencia

• Sapphire es un software experimental y en desarrollo activo, por lo que puede ser inestable
• Si reinstalas con Sapphire un cask instalado con brew, se instalará en una ruta ligeramente distinta y la configuración del usuario no se migrará automáticamente

⚙️ Estructura del proyecto

• sapphire-core: biblioteca central encargada de importar paquetes, resolver dependencias, extraer archivos y procesar artefactos
• sapphire-cli: interfaz de línea de comandos donde el ejecutable sapphire envuelve la biblioteca central

🚀 Hoja de ruta

1. Actualizar los paquetes instalados con el comando upgrade
2. Limpiar descargas antiguas, versiones y caché
3. Comando Reinstall para reinstalaciones rápidas
4. Prefix isolation para admitir /opt/sapphire con un diseño independiente
5. Asistente sapphire init para bootstrapear el entorno
6. Corrección continua de errores y mejoras de estabilidad

📦 Uso

• Mostrar ayuda: sapphire --help
• Actualizar metadatos: sapphire update
• Buscar paquetes: sapphire search
• Obtener información de un paquete: sapphire info
• Instalar un Bottle o Cask: sapphire install
• Compilar e instalar una Formula desde el código fuente: sapphire install --build-from-source
• Desinstalar: sapphire uninstall
• (Próximamente) sapphire upgrade [--all] , sapphire cleanup, sapphire init

🏗️ Compilar desde el código fuente

Requisito previo: cadena de herramientas estable de Rust

• git clone
• cd sapphire
• cargo build --release
• El binario sapphire se encuentra en target/release/sapphire; agrégalo al PATH

[GN⁺]

Comentarios en Hacker News

• Dice que su proyecto no es mejor que Homebrew en muchos aspectos, pero está resolviendo algunos problemas como la configuración de rutas relativas

  • La mayoría de las instalaciones de bottles, excepto Rust, funcionan bien
  • Las fórmulas que se compilan desde el código fuente son difíciles debido a la falta de información en la API JSON
  • Planea convertir los scripts .rb a un formato de lectura mecánica más general
  • La conversión de .dmg a .app y los instaladores .pkg funcionan bien según las pruebas
  • Como la mayoría de las fórmulas se ofrecen como bottles en las Mac ARM modernas, puede convertirse en un gestor de paquetes completo
  • Como Ansible le parece excesivo para una sola máquina, está desarrollando un gestor declarativo de paquetes y del sistema para macOS
  • Envolver el comando brew era demasiado lento, lo que lo llevó a iniciar un proyecto nuevo
  • Agradece los reportes de errores, issues y pull requests constructivos

• Explica dos partes clave de Homebrew

  • Del lado del cliente, la mayoría de los usuarios usan instalaciones de bottles y plataformas compatibles, algo que puede cubrirse fácilmente con un pequeño instalador de código nativo
  • Los desarrolladores, repositorios y máquinas de CI/CD conforman la compleja infraestructura de Homebrew, la cual está profundamente ligada a su DSL de fórmulas
  • Homebrew aísla bien el lado del cliente de esa infraestructura compleja
  • Las descargas paralelas de bottles y DMG no son una limitación de la arquitectura de Homebrew, sino una elección por cortesía hacia el servicio

• Considera que el proyecto es divertido y está bien hecho

  • Es crítico con que se mantenga la terminología de Homebrew
  • Sugiere que sería mejor usar términos estándar como paquetes y repositorios

• Cuestiona que el objetivo sea alcanzar paridad con Homebrew

  • Sugiere funciones adicionales como el fijado de versiones

• Dice que fue usuario de MacPorts, pero explica por qué cambió a Homebrew

  • Cree que crear un nuevo gestor de paquetes no dará como resultado una mejor configuración

• Sugiere agregar objetivos, motivación y razones al README

  • Hace falta dejar más claro por qué se intenta resolver los problemas de Homebrew

• Reconoce que Homebrew puede mejorar y da la bienvenida a nuevos intentos

  • Expresa descontento con las intenciones y la forma de pensar de los desarrolladores y empaquetadores de Homebrew

• Sugiere cambiar el nombre del proyecto por uno más corto

  • Un nombre corto podría ser más memorable y dar una sensación más ligera

• Sostiene que reescribir el software desde cero no es efectivo

  • Sugiere que sería mejor reemplazar gradualmente los componentes de Homebrew
  • Explica que el nombre Homebrew es culturalmente importante dentro de los grupos de hackers