7P by neo 3달전 | favorite | 댓글 2개
  • uv는 Rust로 작성된 초고속 Python 패키지 installer 및 resolver로, pippip-tools 워크플로우를 대체하기 위해 설계됨
  • uv는 "Cargo for Python"을 향한 이정표로, 빠르고, 신뢰할 수 있으며 사용하기 쉬운 종합적인 Python 프로젝트 및 패키지 관리자
  • Rye, Armin Ronacher가 실험적으로 개발한 Python 패키징 도구의 관리를 인수하여 uv를 통합된 후속 프로젝트로 확장할 계획

성능에 대한 집착적인 초점

  • uv는 캐싱 없이 pippip-tools보다 8-10배 빠르며, 캐시가 있을 때는 80-115배 빠름.
  • 전역 모듈 캐시를 사용하여 의존성을 다시 다운로드하거나 빌드하지 않고, 지원되는 파일 시스템에서 Copy-on-Write 및 하드링크를 활용하여 디스크 공간 사용을 최소화함.

채택 최적화

  • uv의 초기 릴리스는 pippip-tools API를 지원하며, 기존 프로젝트에서 구성 변경 없이 사용 가능함.
  • uv는 단일 정적 바이너리로 제공되며, pip, pip-tools, virtualenv를 대체할 수 있음.
  • Python 버전에 따라 pip 설치를 관리할 필요 없이 Python 자체와 별도로 설치할 수 있음.

"Cargo for Python": uv와 Rye

  • uv는 빠르고, 신뢰할 수 있으며 사용하기 쉬운 통합된 Python 패키지 및 프로젝트 관리자를 향한 중간 이정표임.
  • uv는 pip, pip-tools, virtualenv 뿐만 아니라 pipx, tox, poetry, pyenv, ruff 등을 포함하는 단일 바이너리를 목표로 함.

호환 가능 API

  • pip install 대신 uv pip install을 사용하여 Python 의존성을 명령줄, 요구 사항 파일 또는 pyproject.toml에서 설치할 수 있음.
  • pip-compile 대신 uv pip compile을 사용하여 잠긴 requirements.txt를 생성할 수 있음.
  • pip-sync 대신 uv pip sync을 사용하여 잠긴 requirements.txt와 가상 환경을 동기화할 수 있음.

로드맵

  • 이 릴리스 이후, 사용자 지원을 우선시하며 호환성, 성능 및 안정성 향상에 집중할 계획임.
  • 이후에는 uv를 완전한 Python 프로젝트 및 패키지 관리자로 확장하는 것을 목표로 함.

감사의 말

  • uv 개발에 직접적으로 또는 간접적으로 기여한 모든 이들에게 감사를 표함.
  • 특히, PubGrub의 기본 버전 해결자로서 uv에 사용되는 Jacob Finkelman과 Matthieu Pizenberg에게 감사함.

GN⁺의 의견

  • uv는 Python 개발자들에게 기존 pip 도구보다 훨씬 빠른 성능을 제공하여 프로젝트 설정 시간을 크게 단축시킬 수 있는 혁신적인 도구임.
  • Rust로 작성되어 Python 생태계 내에서 성능과 안정성을 중시하는 새로운 트렌드를 반영하고 있으며, 이는 개발자 경험을 크게 향상시킬 것으로 기대됨.
  • uv의 개발은 Python 패키징 및 프로젝트 관리 도구의 통합을 지향하며, 이는 개발자들이 보다 효율적이고 일관된 방식으로 작업할 수 있게 할 것임.

확장되서 conda를 대체할수있으면 좋겠네요

Hacker News 의견
  • VC-backed pip-and-more에 대한 의문

    • 벤처 자본으로 지원받는 pip-and-more가 무료 자금 프린터가 고장 났을 때 어떻게 수익을 낼 것인지 이해하기 어려움.
  • uv의 플랫폼 독립적인 lockfile 생성 미지원에 대한 질문

    • uv가 Poetry나 PDM과 달리 플랫폼 독립적인 lockfile을 생성하지 않는 것에 대해, 이러한 접근이 요구사항 파일에 종속되어 있다고 생각하며, "Python의 Cargo"를 목표로 하는 것에 부합하지 않는다고 봄.
  • uv의 대체 의존성 해결 전략 지원에 대한 긍정적인 평가

    • uv가 기본적으로 최신 호환 가능한 패키지 버전을 선호하는 표준 Python 의존성 해결 전략을 따르지만, --resolution=lowest 옵션을 통해 가장 낮은 호환 가능한 버전으로 테스트할 수 있는 기능을 제공함.
    • uv가 --python-version 매개변수를 통해 현재 설치된 Python 버전과 다른 버전에 대한 해결책을 생성할 수 있는 기능을 제공하는 것은 훌륭함.
  • Python 패키지 시스템의 복잡성에 대한 의문

    • Python 인터프리터의 가치관에 "하나의 명확한 방법이 있어야 한다"는 원칙이 포함되어 있는데, 어떻게 이렇게 복잡한 패키징 이야기가 나오게 되었는지 의문을 제기함.
  • uv가 pubgrub-rs를 사용하는 것에 대한 흥미로운 점

    • uv가 Dart 언어용으로 처음 작성된 pubgrub 버전 해결 알고리즘의 Rust 구현인 pubgrub-rs를 사용하는 것에 대해, 이러한 영감의 연쇄가 언어 간에 이어지는 것을 보는 것이 재미있다고 평가함.
  • Astral 팀의 경로 예측에 대한 언급

    • Astral 팀이 ruff의 기능을 확장하여 Python 개발자가 필요로 하는 모든 것을 수행할 수 있도록 할 것이라는 예측을 11일 전에 했다고 언급함.
  • pip의 속도에 대한 개인적인 경험

    • pip이 대체로 빠르게 작동하지만, 많은 데이터를 다운로드하거나 네이티브 라이브러리를 컴파일하는 데 시간이 걸릴 때 느려짐을 경험함. 반면, conda는 매우 느리고, 심지어 강력한 기계에서도 느림.
  • 새로운 Python 패키지 관리자에 대한 회의적인 견해

    • 또 다른 Python 패키지 관리자가 등장했지만, pip를 대체할 수 있는 것이라면 속도 향상을 위해 ruff로 전환한 것처럼 전환할 수 있을 것임. Python 패키지 관리에 대한 영구적인 해결책이 필요함.
  • uv가 플랫폼 특정 requirements.txt 파일을 생성하는 결정에 대한 궁금증

    • uv가 플랫폼에 구애받지 않는 poetry.lock과 pdm.lock 파일을 생성하는 것이 아니라 플랫폼 특정 requirements.txt 파일을 생성하는 결정에 대한 이유가 궁금함.
  • Astral 팀의 작업에 대한 축하와 긍정적인 반응

    • Astral 팀이 Python 패키징을 "수정"하려는 외부 시도에 대해 염려를 표현했지만, 호환성이 우선시되는 것을 보고 기쁨을 표함. Astral 팀이 기존 도구와 표준에 대한 호환성을 강조하는 데 노력을 기울인 것을 긍정적으로 평가함.
  • pip 패키지의 컴파일 문제에 대한 질문

    • 일부 pip 패키지가 gcc, g++, gtk, Qt 등과 같은 전체 툴체인에 의존하는 컴파일을 요구하는데, 이를 어떻게 덜 오류가 발생하고 사용자 친화적으로 만들 계획인지에 대한 질문.