Sapphire: macOS용 Rust 기반 패키지 관리자 (Homebrew 대체)

 (github.com/alexykn)
4P by GN⁺ | ★ favorite | 댓글 1개
  • Sapphire는 Rust로 개발된 차세대 패키지 관리자임
  • Homebrew에서 영감을 받아 Formulae와 Casks를 설치 및 관리함
  • 현재 ARM 아키텍처만 지원하며, x86 지원은 추후 추가될 가능성이 있음
  • 프로젝트는 sapphire-core와 sapphire-cli로 구성되어 있음
  • Sapphire는 BSD-3-Clause 라이선스를 따름

경고

  • Sapphire는 실험적이며 활발히 개발 중인 소프트웨어로, 불안정할 수 있음
  • brew로 설치한 cask를 Sapphire로 재설치하면 경로가 약간 다르게 설치되며, 사용자 설정이 자동으로 마이그레이션되지 않음

⚙️ 프로젝트 구조

  • sapphire-core: 핵심 라이브러리로, 패키지 가져오기, 의존성 해결, 아카이브 추출, 아티팩트 처리 등을 담당함
  • sapphire-cli: 명령줄 인터페이스로, sapphire 실행 파일이 핵심 라이브러리를 감쌈

🚀 로드맵

  1. 업그레이드 명령어로 설치된 패키지 업데이트
  2. 오래된 다운로드, 버전, 캐시 정리
  3. 빠른 재설치를 위한 Reinstall 명령어
  4. /opt/sapphire를 독립 레이아웃으로 지원하는 Prefix isolation
  5. 환경을 부트스트랩하는 sapphire init 도우미
  6. 지속적인 버그 수정 및 안정성 개선

📦 사용법

  • 도움말 출력: sapphire --help
  • 메타데이터 업데이트: sapphire update
  • 패키지 검색: sapphire search
  • 패키지 정보 얻기: sapphire info
  • Bottle 또는 Cask 설치: sapphire install
  • 소스에서 Formula 빌드 및 설치: sapphire install --build-from-source
  • 제거: sapphire uninstall
  • (곧 제공 예정) sapphire upgrade [--all] , sapphire cleanup, sapphire init

🏗️ 소스에서 빌드

필수 조건: 안정적인 Rust 도구 체인

  • git clone
  • cd sapphire
  • cargo build --release
  • sapphire 바이너리는 target/release/sapphire에 위치하며, 이를 PATH에 추가

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견

  • 자신이 만든 프로젝트가 Homebrew보다 나은 점은 많지 않지만, 상대 경로 설정과 같은 몇 가지 문제를 해결 중임

    • Rust를 제외한 대부분의 병(bottle) 설치는 잘 작동함
    • 소스에서 빌드하는 공식은 JSON API의 정보 부족으로 인해 어려움이 있음
    • .rb 스크립트를 더 일반적인 기계 판독 형식으로 변환할 계획임
    • .dmg에서 .app으로의 변환과 .pkg 설치 프로그램은 테스트를 통해 잘 작동함
    • 현대 ARM Mac에서 대부분의 공식이 병으로 제공되므로 완전한 패키지 관리자가 될 수 있음
    • Ansible이 한 대의 기계에 과도하다고 느껴서 mac을 위한 선언적 패키지 및 시스템 관리자를 개발 중임
    • Brew 명령어를 감싸는 것이 너무 느려서 새로운 프로젝트를 시작하게 되었음
    • 버그 보고, 이슈 및 건설적인 풀 리퀘스트에 감사함

  • Homebrew의 두 가지 핵심 부분에 대해 설명함

    • 클라이언트 측은 대부분의 사용자가 병 설치와 지원 플랫폼을 사용하며, 소규모 네이티브 코드 설치 프로그램으로 쉽게 지원 가능함
    • 개발자, 저장소, CI/CD 기계는 Homebrew의 복잡한 인프라를 구성하며, 이는 공식 DSL과 깊이 연결되어 있음
    • Homebrew는 클라이언트 측을 복잡한 인프라로부터 잘 격리하고 있음
    • 병과 DMG의 병렬 다운로드는 Homebrew의 아키텍처 제한이 아니라 서비스에 대한 예의를 위해 선택한 것임

  • 프로젝트가 재미있고 잘 만들어졌다고 평가함

    • Homebrew의 용어를 유지하는 것에 대해 비판적임
    • 패키지와 저장소 같은 표준 용어를 사용하는 것이 더 나을 것이라고 제안함

  • Homebrew와의 동등성을 목표로 하는 것에 의문을 제기함

    • 버전 고정 기능과 같은 추가 기능을 제안함

  • MacPorts 사용자였지만 Homebrew로 전환한 이유를 설명함

    • 새로운 패키지 관리자를 만드는 것이 더 나은 설정을 만들지는 않을 것이라고 생각함

  • README에 목표, 동기, 이유를 추가할 것을 제안함

    • Homebrew의 문제점을 해결하려는 이유를 명확히 할 필요가 있음

  • Homebrew의 개선 가능성을 인정하며, 새로운 시도를 환영함

    • Homebrew의 개발자와 패키저의 의도와 사고방식에 불만을 표함

  • 프로젝트 이름을 더 짧게 변경할 것을 제안함

    • 짧은 이름이 더 기억에 남고 가벼운 느낌을 줄 수 있음

  • 소프트웨어를 새로 작성하는 것은 효과적이지 않다고 주장함

    • Homebrew의 구성 요소를 점진적으로 교체하는 것이 더 나을 것이라고 제안함
    • Homebrew라는 이름이 해커 그룹에서 문화적으로 중요하다고 설명함
답변달기