GN⁺: 라이와 우브: 8월은 Python Packaging 수확 시즌
(lucumr.pocoo.org)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 사용자는 만족함
-
패키지 관리자를 개발하는 것에 열정을 가진 사람들이 있음
- 이러한 상황이 계속된다면 매년 새로운 패키지 관리자가 나올 것임