2P by neo 3달전 | favorite | 댓글 1개

Armin Ronacher의 생각과 글

Python 패키징을 위한 Rye와 uv: 8월은 수확의 계절

  • 몇 달 전, Rye 패키징 도구의 관리권을 Astral에 넘겼음
  • Astral 팀은 지난 몇 달 동안 Python 패키징을 위한 많은 도구를 개발해왔음
  • 최근 릴리스에서 uv는 pyproject.toml 파일 조작, 워크스페이스 지원, 로컬 패키지 참조 및 스크립트 설치와 같은 기능을 추가했음
  • uv는 Python 설치도 관리할 수 있어 Rye와 매우 유사해짐
  • Rye를 사용하는 사람들은 uv를 주목하고 피드백을 제공해야 함

EuroPython에서의 발표

  • 최근 프라하에서 열린 EuroPython에서 Python 패키징에 대한 견해와 Rye를 만들면서 배운 교훈을 발표했음
  • 패키징 도구의 목표는 모든 사람이 사용하는 최고의 도구가 되는 것임
  • Python은 AI와 ML의 투자와 관심 덕분에 매우 인기 있는 플랫폼이 되었음
  • Python을 배우는 사람들이 훌륭한 개발자 경험을 기억하도록 하고 싶음
  • 현재는 너무 많은 도구와 불일치로 인해 어려움이 있음

도구의 지배

  • 지배는 대부분의 투자가 하나의 스택으로 들어간다는 것을 의미함
  • Rye와 같은 도구는 지배적인 도구가 확립되면 사라져야 함
  • uv가 그 도구가 될 가능성이 높음
  • 최종적으로 Rye는 uv로 대체될 것임

패키징 생태계의 발전

  • 많은 패키징 도구가 Python 생태계의 발전을 기반으로 구축되었음
  • setup.py 파일에서 eggs, wheels로의 전환, 메타데이터 표준의 도입 등 많은 발전이 있었음
  • Rust crates와 Python 라이브러리의 발전이 이러한 도구를 가능하게 했음

커뮤니티의 다음 단계

  • 커뮤니티는 더 적은 도구를 추천해야 함
  • ez_setup.py와 easy_install을 추천하던 시절이 있었음
  • 현재는 pip, pip-tools, poetry, PDM 등을 추천함
  • 중요한 Python 프로젝트를 유지하는 사람들은 uv를 시도해보고 추천할지 고려해야 함

Astral의 VC 자금

  • Astral이 VC 자금을 받는다는 점이 미래에 어떤 영향을 미칠지 고민해야 함
  • 코드와 uv의 기능을 보면, 최악의 경우에도 커뮤니티는 uv가 존재하기 전보다 나아질 것임

GN⁺의 정리

  • 이 글은 Python 패키징 도구의 발전과 커뮤니티의 역할에 대해 다루고 있음
  • uv는 많은 기능을 제공하며, Rye를 대체할 가능성이 높음
  • 커뮤니티는 더 적은 도구를 추천하고, uv를 시도해볼 필요가 있음
  • Astral의 VC 자금이 미래에 미칠 영향을 고려해야 함
  • 비슷한 기능을 가진 도구로는 pip, poetry, PDM 등이 있음
Hacker News 의견
  • uv의 최신 릴리스가 Home Assistant의 릴리스 프로세스를 크게 단축시켰음

    • 릴리스 시간이 약 2.5시간에서 약 20분으로 줄어듦
    • 자세한 내용은 Home Assistant 개발자 블로그에서 확인 가능함
  • 처음에는 새로운 도구가 Python "패키징" 문제를 해결할 것이라고 기대했으나, 실제로는 패키지 관리에 관한 것임

    • 개인적으로 Python 패키지 관리에는 큰 문제가 없었음
    • pip는 일반적으로 잘 작동함
  • Python에서 애플리케이션을 실행 파일로 쉽게 포장할 수 없는 점이 불편함

    • 프로덕션 환경에서 git 클론과 virtualenv 생성을 자주 봄
    • 이는 보안 관점에서 좋지 않음
  • Python 패키징에 문제가 있지만, 기본 pip로도 꽤 잘 해왔음

    • 원래 virtualenv에서 내장된 venv 모듈로 전환한 것이 큰 변화였음
    • 의존성 관리를 진지하게 하려면 FAANG처럼 모노레포를 구축하는 것이 좋음
  • npm VC 사기와 Microsoft 인수, OpenAI의 법적 비영리 상태로 인해 주요 언어 인프라를 이러한 조직에 맡기기 꺼려짐

    • 개별 기여자들은 훌륭하지만, 조직 차원의 재정적 정렬이 문제임
    • 빠른 린트, 타입 체크, 코드 스캔, PR 어시스턴트는 언제든지 교체 가능하지만, 설치 흐름과 패키지 저장소는 아님
  • 이러한 도구들의 문제는 권위임

    • pypa의 승인을 받지 못했기 때문에 cargo와 다름
    • pypa가 포괄적인 솔루션을 제공하지 못했음
    • 3-4년 전만 해도 poetry와 pipenv가 문제를 해결할 것처럼 보였음
    • pypa가 astral.sh에 참여해야 하지만, 통제 없이 할 수 있을지 의문임
  • Armin은 'uv'가 이 분야를 지배해야 한다고 주장하지만, VC 지원으로 인해 문제가 발생할 수 있음을 인정함

    • 그의 해결책은 'uv'가 매우 포크 가능하다는 것임
    • 그러나 포크는 더 많은 분열을 초래함
  • 회사에서 poetry의 느린 속도로 인해 uv로 소프트웨어를 마이그레이션하려고 함

    • 많은 문서를 읽었지만, 실제로 한 일은 많지 않음
    • 이전에 poetry로의 마이그레이션은 훨씬 간단했음
    • uv는 여전히 많은 Python 패키지 문제를 유지하고 있음
  • 사람들이 이번 라운드를 건너뛰고 2026년의 "Python 패키지 관리자: 이번에는 정말 해결했다!"를 기다리는 것도 이해할 수 있음

    • 여전히 Nix 사용자는 만족함
  • 패키지 관리자를 개발하는 것에 열정을 가진 사람들이 있음

    • 이러한 상황이 계속된다면 매년 새로운 패키지 관리자가 나올 것임