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라는 이름이 해커 그룹에서 문화적으로 중요하다고 설명함