이 게시물의 제목은 Glyph의 Python Packaging is Good Now에 대한 참조입니다. 지난 8년 동안 우리는 "좋음"에서 "훌륭함"으로 변했다고 해도 무방할 것 같습니다. 내 추론을 계속 읽으십시오.

초보자가 Python 패키징을 어렵게 만드는 이유는 무엇입니까?

나는 Python 패키징의 두 가지 주요 어려움은 다음과 같다고 주장합니다.

• 부트스트래핑, 즉 시작하는 방법!
• 활성화, 즉 Python의 venvs 작동 방식(내 Mastodon 스레드를 참조하세요. 설명하기가 너무 어렵습니다!)

부트스트래핑은 종종 무시되는 문제였습니다. 사람들에게 https://python.org에서 Python을 설치하라고 알려야 할까요? 아나콘다 배포판? 사람들이 시스템 패키지 관리자를 사용하지 못하게 하고 모든 것을 망칠 위험을 감수하려면 어떻게 해야 합니까?

그리고 전체 가상 환경 수명주기를 잊지 마세요. 오랫동안 파이썬을 사용하다보니 너무 무감각해졌는데, 설명해야 할 때마다 학생들의 표정을 보며 '이건 안 된다'는 생각이 듭니다.

물론, 배포 가능한 패키지를 빌드하고 게시하는 방법과 같은 다른 문제도 있습니다. 그러나 나는 이것이 대부분의 Python 초보자에 영향을 미치지 않는다고 주장합니다. 게다가, 그것들도 해결되는 과정에 있습니다. 계속 읽어보세요.

자외선을 입력하세요

2월 15일 Astral이 uv를 출시했고 저는 즉시 뛰어들었습니다. 업무의 일환으로 저는 잠재적으로 충돌할 수 있는 많은 종속성을 정기적으로 설치해야 하는데 uv가 즉시 해결되었습니다.

그러나 흥미로운 점은 이제 uv가 초기의 "빠른 pip" 단계를 훨씬 뛰어넘어 "빠르고 안정적이며 사용하기 쉬운 포괄적인 Python 프로젝트 및 패키지 관리자"라는 약속을 이행하고 있다는 것입니다.

처음에 언급한 부트스트래핑 및 활성화 문제로 돌아가서 uv는 이를 어떻게 해결합니까? 다음을 고려하십시오:

• uv는 Python 자체에 의존하지 않습니다. 사전 컴파일된 독립 실행형 바이너리는 Linux, macOS 및 Windows에 쉽게 설치할 수 있습니다.
• uv python은 Python 버전을 관리합니다! pyenv, deadsnakes와 같은 OS별 메커니즘이나 conda와 같은 무거운 도구에 의존할 필요가 없습니다.
• uv 도구는 중앙 집중식 환경에서 도구를 관리합니다! 더 이상 Pipx나 페이드가 필요하지 않습니다.
• uv init는 해칭을 빌드 백엔드로 사용하고 빈 README와 더미 모듈이 있는 작동하는 src 레이아웃을 사용하여 베어본 pyproject.toml을 생성합니다.
  • 더 정교한 것이 필요하다면 언제든지 더 정교한 템플릿과 함께 복사기나 쿠키커터를 사용할 수 있습니다.
• uv add는 pyproject.toml에 종속성을 추가하고, venv가 없으면 생성하고, 설치합니다!
• uv lock은 모든 종속성이 포함된 잠금 파일을 생성한 다음 uv sync에서 사용할 수 있습니다.
  • 그리고 오래된 요구사항.txt를 원한다면 pip-tools처럼 uv pip compile이 이를 수행합니다!
• uv run은 환경을 명시적으로 활성화하지 않고 스크립트와 명령을 다시 실행합니다!

기본적으로 다음은 다음과 같습니다.

$ mkdir uv-playground
$ cd uv-playground
$ uv init
warning: `uv init` is experimental and may change without warning
Initialized project `uv-playground`
$ uv add click
warning: `uv add` is experimental and may change without warning
Using Python 3.12.3 interpreter at: /usr/bin/python3
Creating virtualenv at: .venv
Resolved 3 packages in 66ms
   Built uv-playground @ file:///tmp/uv-playground
Prepared 2 packages in 430ms
Installed 2 packages in 0.62ms
   click==8.1.7
   uv-playground==0.1.0 (from file:///tmp/uv-playground)
$ tree
.
├── pyproject.toml
├── README.md
├── src
│   └── uv_playground
│       ├── __init__.py
└── uv.lock

3 directories, 4 files
$ uv run python -c "from uv_playground import hello; print(hello())"
warning: `uv run` is experimental and may change without warning
Hello from uv-playground!

따라서 "내 컴퓨터에서 Python 학습을 시작하려면 어떻게 해야 합니까?"라는 질문에 이제 "uv 설치"라고 보편적으로 응답할 수 있습니다.

일부 반성

가상 환경에 관한 Armin의 말에 저는 기본적으로 동의합니다.

npm은 "활성화"와 동등한 기능 없이 사라졌으며 미래의 Python 생태계에서도 virtualenv 활성화가 더 이상 많이 사용되지 않을 것이라고 생각합니다.

또한 uv init가 hatchling을 선택했다는 것도 알아냈습니다. 저는 항상 PDM에 대한 선호도가 조금 있었는데, 이 점은 어쩌면 돌아갈 수 없는 지점이 아닐까 생각합니다.

Leah와 기여자들은 PyOpenSci 패키징 가이드에 대한 결정 다이어그램을 작성하는 데 많은 작업이 필요했습니다. 그러나 이제 더 구체적인 요구 사항(예: Meson 또는 scikit 빌드 가능 빌드 백엔드)이 있는 경우 사람들이 변경할 수 있는 기준이 있다는 사실은 다시 훨씬 더 나은 개발자 경험을 제공합니다.

콘다에서

conda 대 pip라는 주제는 또 다른 일반적인 혼란의 원인입니다. 저는 처음부터 conda 사용자이자 팬이었습니다. Windows에 설치하는 것이 매우 어려웠을 때 Python이 확실히 죽음으로부터 효과적으로 구해졌습니다.

그 후 몇 년 동안 저는 차이점을 설명하는 Jake VanderPlas의 오래된 블로그 게시물을 자주 참조했지만 지금은 그 내용이 사라진 것처럼 보입니다.

pip와 conda 사이의 상호 운용성 문제는 완전히 해결되지 않았으며 Pixi 사람들이 환상적인 일을 하고 있다고 생각하지만 장기적으로는 uv가 승리할 것이라고 생각합니다.

나는 conda 패키지가 비 Python 코드 개념을 중심으로 더 잘 구성되어 있으며 현재 "PyPI의 뚱뚱한 바퀴" 세계가 분명히 차선책이라는 점을 충분히 인정합니다. 그러나 전체 생태계는 그 방향으로 움직였습니다. 이제 대부분의 패키지는 다양한 플랫폼에 대해 사전 컴파일된 휠을 게시합니다.

즉, conda는 2014년만큼 유용하지 않을 수 있으며 이제 초보자에게 conda를 가르치는 것을 중단하고 고급 도구로 간주해야 할 때일 수도 있습니다.

결론

조금 너무 이른 이유는 이러한 uv 명령 중 일부가 아직 실험적이며 앞으로 발전할 수 있기 때문입니다. 하지만 처음으로 표준을 준수하고 포괄적이며 부트스트래핑 문제가 없고 세심하게 설계되었으며 승리

많은 Python 패키징 비평가들이 원했던 것은 무엇입니까? 다양한 도구 중에서 선택할 필요가 없습니다. 하지만 uv는 그 이상으로 다른 개발자 경험 문제를 해결했다고 생각합니다. 이에 대해 기쁘고 감사합니다.

저는 모든 일에 UV를 효과적으로 사용하고 있으며 뒤돌아보지 않습니다. 저는 계속해서 이 도구를 모든 사람에게 추천하고 이에 대해 계속 이야기하며 이 도구가 더 널리 퍼지기를 바랍니다.