Sapphire: gerenciador de pacotes para macOS baseado em Rust (alternativa ao Homebrew)

• Sapphire é um gerenciador de pacotes de próxima geração desenvolvido em Rust
• Inspirado no Homebrew, instala e gerencia Formulae e Casks
• Atualmente oferece suporte apenas à arquitetura ARM; o suporte a x86 poderá ser adicionado futuramente
• O projeto é composto por sapphire-core e sapphire-cli
• Sapphire segue a licença BSD-3-Clause

---

Aviso

• Sapphire é um software experimental e em desenvolvimento ativo, podendo ser instável
• Se você reinstalar com o Sapphire um cask instalado com brew, ele será instalado em um caminho ligeiramente diferente, e as configurações do usuário não serão migradas automaticamente

⚙️ Estrutura do projeto

• sapphire-core: biblioteca principal, responsável por buscar pacotes, resolver dependências, extrair arquivos e processar artefatos
• sapphire-cli: interface de linha de comando, na qual o executável sapphire encapsula a biblioteca principal

🚀 Roteiro

1. Comando upgrade para atualizar pacotes instalados
2. Limpeza de downloads, versões e cache antigos
3. Comando Reinstall para reinstalação rápida
4. Prefix isolation com suporte a /opt/sapphire como layout independente
5. Assistente sapphire init para inicializar o ambiente
6. Correções contínuas de bugs e melhorias de estabilidade

📦 Uso

• Exibir ajuda: sapphire --help
• Atualizar metadados: sapphire update
• Buscar pacote: sapphire search
• Obter informações do pacote: sapphire info
• Instalar Bottle ou Cask: sapphire install
• Compilar e instalar Formula a partir do código-fonte: sapphire install --build-from-source
• Remover: sapphire uninstall
• (em breve) sapphire upgrade [--all] , sapphire cleanup, sapphire init

🏗️ Compilar a partir do código-fonte

Pré-requisito: toolchain estável do Rust

• git clone
• cd sapphire
• cargo build --release
• O binário sapphire fica em target/release/sapphire; adicione-o ao PATH

[GN⁺]

Comentários do Hacker News

• O autor afirma que o projeto que criou não é muito melhor que o Homebrew, mas está resolvendo alguns problemas, como a configuração de caminhos relativos

  • A instalação da maioria dos bottles, exceto os do Rust, funciona bem
  • Fórmulas que compilam a partir do código-fonte são difíceis devido à falta de informações na API JSON
  • Há planos de converter scripts .rb para um formato de leitura por máquina mais genérico
  • A conversão de .dmg para .app e instaladores .pkg funciona bem nos testes
  • Como a maioria das fórmulas é fornecida como bottle nos Macs ARM modernos, isso pode se tornar um gerenciador de pacotes completo
  • Como o Ansible parece exagerado para uma única máquina, o autor está desenvolvendo um gerenciador declarativo de pacotes e sistema para Mac
  • Envolver os comandos do Brew era lento demais, o que levou ao início de um novo projeto
  • Agradece por relatórios de bugs, issues e pull requests construtivos

• Explica duas partes centrais do Homebrew

  • No lado do cliente, a maioria dos usuários usa instalação por bottle e plataformas suportadas, o que pode ser atendido com facilidade por um pequeno instalador em código nativo
  • Desenvolvedores, repositórios e máquinas de CI/CD compõem a infraestrutura complexa do Homebrew, que está profundamente ligada à DSL das fórmulas
  • O Homebrew isola muito bem o lado do cliente da infraestrutura complexa
  • O download paralelo de bottles e DMGs não é uma limitação da arquitetura do Homebrew, mas uma escolha feita por consideração ao serviço

• Avalia o projeto como divertido e bem-feito

  • Faz uma crítica à manutenção da terminologia do Homebrew
  • Sugere que usar termos padrão como pacote e repositório seria melhor

• Questiona o objetivo de alcançar paridade com o Homebrew

  • Sugere recursos adicionais, como fixação de versão

• Diz que era usuário do MacPorts, mas explica por que migrou para o Homebrew

  • Acha que criar um novo gerenciador de pacotes não levará necessariamente a uma configuração melhor

• Sugere adicionar objetivos, motivação e razões ao README

  • É preciso deixar mais claro por que se quer resolver os problemas do Homebrew

• Reconhece que o Homebrew pode melhorar e vê com bons olhos uma nova tentativa

  • Expressa insatisfação com as intenções e a forma de pensar dos desenvolvedores e empacotadores do Homebrew

• Sugere mudar o nome do projeto para algo mais curto

  • Um nome curto pode ser mais memorável e passar uma sensação mais leve

• Argumenta que reescrever o software do zero não é eficaz

  • Sugere que seria melhor substituir gradualmente os componentes do Homebrew
  • Explica que o nome Homebrew tem importância cultural em grupos de hackers