Sapphire: macOS용 Rust 기반 패키지 관리자 (Homebrew 대체)
(github.com/alexykn)- Sapphire는 Rust로 개발된 차세대 패키지 관리자임
- Homebrew에서 영감을 받아 Formulae와 Casks를 설치 및 관리함
- 현재 ARM 아키텍처만 지원하며, x86 지원은 추후 추가될 가능성이 있음
- 프로젝트는 sapphire-core와 sapphire-cli로 구성되어 있음
- Sapphire는 BSD-3-Clause 라이선스를 따름
경고
- Sapphire는 실험적이며 활발히 개발 중인 소프트웨어로, 불안정할 수 있음
- brew로 설치한 cask를 Sapphire로 재설치하면 경로가 약간 다르게 설치되며, 사용자 설정이 자동으로 마이그레이션되지 않음
⚙️ 프로젝트 구조
- sapphire-core: 핵심 라이브러리로, 패키지 가져오기, 의존성 해결, 아카이브 추출, 아티팩트 처리 등을 담당함
-
sapphire-cli: 명령줄 인터페이스로,
sapphire
실행 파일이 핵심 라이브러리를 감쌈
🚀 로드맵
- 업그레이드 명령어로 설치된 패키지 업데이트
- 오래된 다운로드, 버전, 캐시 정리
- 빠른 재설치를 위한 Reinstall 명령어
-
/opt/sapphire
를 독립 레이아웃으로 지원하는 Prefix isolation - 환경을 부트스트랩하는
sapphire init
도우미 - 지속적인 버그 수정 및 안정성 개선
📦 사용법
- 도움말 출력:
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
에 추가
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라는 이름이 해커 그룹에서 문화적으로 중요하다고 설명함