uv-build를 빌드 백엔드로 쓰지 말아 달라는 요청

AI 요약

Gentoo에서 패키지 여러 개가 의존성 하나의 빌드 백엔드 전환 때문에 키워드를 잃었습니다. 글쓴이는 그 사례를 들어 순수 Python 패키지의 백엔드로 uv-build를 선택하지 말아 달라고 요청합니다. 비판 대상은 uv나 Astral의 다른 도구가 아니라 uv-build이며, 글쓴이는 기능 자체가 나쁘다고 하지 않고 이점이 단점보다 작다고 주장합니다.

의존성과 빌드 빈도

uv-build는 Rust로 작성됐고 의존성이 큽니다. 글에 따르면 0.13.0 버전의 휠 크기는 플랫폼에 따라 1.2~1.5MiB입니다. 반면 순수 Python 백엔드인 flit-core의 휠은 45KiB입니다. Gentoo 사용자는 uv-build를 소스에서 빌드해야 하며, 글을 쓸 당시 직전 30일 동안 uv-build가 12번 출시됐습니다. 글쓴이는 패키지 하나를 uv-build로 설치할 때 빌드 시간이 100밀리초 줄더라도, Gentoo 사용자가 uv-build 새 버전을 반복해서 빌드하는 데는 여러 시간이 들 수 있다고 설명합니다.

글쓴이가 더 큰 문제로 꼽는 부분은 이식성입니다. Python은 C 컴파일러가 작동하는 여러 환경에서 실행할 수 있지만, Rust 지원 플랫폼은 늘어나는 속도가 느리며 Rust 컴파일러가 있어도 uv가 작동하지 않을 수 있습니다. 예로 rustix::fs와 그 의존성이 별다른 이유 없이 SPARC를 지원하지 않는 경우를 듭니다. 32비트 플랫폼에서는 실행 파일이 커져 툴체인의 주소 공간을 소진할 수도 있습니다. Gentoo의 uv ebuild에는 32비트 환경에서 uv를 빌드하기 위한 우회책 두 가지가 이미 들어 있습니다. 지원하지 않는 플랫폼을 새로 추가하고 유지하는 작업도 잦은 코드 변경을 따라가야 하는 큰 부담이라고 말합니다.

성능 이점과 실제 사용자

글쓴이는 uv-build를 선택하는 이유로 uv와의 일관성과 성능을 듭니다. 하지만 PEP 517에 따라 빌드 프런트엔드와 백엔드는 별개이므로 uv를 쓰면서 flit-core나 hatchling 같은 다른 백엔드를 선택할 수 있다고 설명합니다. 성능 차이도 드물게 실행되는 작업에서 약 100밀리초 수준이며, uv-build 휠을 내려받는 시간이 이득을 상쇄할 수 있다고 봅니다.

일반 사용자는 대개 휠을 설치합니다. 백엔드를 직접 쓰는 쪽은 프로젝트 개발자와 기여자, CI/CD 작업, 하위 배포판 패키지 관리자, 소스 배포본 사용자입니다. 글쓴이는 이 가운데 소스 배포본 사용자가 가장 많고 uv-build를 빌드하는 부담도 받으므로, 빌드 시간 단축이 이들에게 돌아가는 이득보다 비용이 크다고 주장합니다.

Lobsters 반응

• @yossarian — 저는 uv 유지관리자입니다. Python 패키징의 좋은 점은 표준화되어 있다는 점입니다. uv의 빌드 백엔드가 필요한 조건에 맞지 않으면 패키징 표준을 잘 따르는 다른 백엔드를 사용할 수 있습니다. 다만 Gentoo가 uv-build의 모든 출시 버전을 다시 빌드해야 하는 이유는 모르겠습니다. uv-build는 uv만큼 자주 바뀌지 않고 의도적으로 uv 버전 간 호환성을 유지합니다. 중요한 호환성 파괴 변경이나 버그 수정은 예외로 두고 매주 한 번이나 그보다 드물게 업데이트하는 정책을 정하면 어떨까요? uv-build가 자주 출시되는 유일한 이유는 내부 구성 요소를 나머지 uv와 같은 시점에 맞추기가 쉽기 때문입니다. Python 빌드 백엔드 메타데이터에서 일반적인 버전 범위를 지정하면 uv는 이미 설치된 uv-build를 사용할 수 있습니다.
  • @misty — Gentoo가 uv-build를 매번 다시 빌드해야 하는 이유는 좋은 질문입니다. 빠르게 바뀌는 의존성에 Gentoo가 어떤 정책을 쓰는지는 잘 모르겠습니다. uv-build가 uv에 묶여 있다면 업데이트 빈도를 낮추기 어렵겠다고 생각했는데 별도 패키지가 있네요. uv가 출시될 때마다 uv-build도 별도로 출시되니 업데이트 주기를 얼마나 길게 잡아도 되는지 분명하지 않을 수 있습니다. 외부 패키지 관리자를 위한 공식 안내에 "N일마다 한 번만 업데이트해도 괜찮다"고 적으면 도움이 될 것 같습니다.
  • @yossarian — 맞습니다. uv에는 uv-build가 포함되어 있으므로 semver 호환 버전의 uv-build를 쓴다면 대부분의 빌드에서 별도로 백엔드를 내려받을 필요도 없습니다. 문서화가 도움이 된다는 점도 좋습니다. 현재 안내를 확인하겠습니다. 외부 패키지 관리자를 위한 조언까지 확장할 수 있을 것 같습니다. 다만 소스 기반 배포판마다 같은 문제가 있는 것은 아니라서 모두에게 맞는 표현을 찾기는 까다로울 수 있습니다.
• @maximilian — 다른 빌드 백엔드는 설정 API가 부족하거나 작업에 따라 사용하기 불편할 수 있다는 점도 글에서 다루지 않았습니다. 예전에 hatchling에서 생성됐지만 gitignore에 포함된 파일을 패키지에 넣으려다 정말 애를 먹었습니다. 그 외에는 잘 쓴 글입니다. uv-build를 배포판 패키지 관리자 관점에서 생각해 본 적이 없었습니다. Python 패키지를 그런 저장소에 넣어야 하는지는 확신이 없지만 그건 배포판의 선택입니다.
• @hsivonen — 레거시 CPU를 취미로 다루는 사람들을 지원하려고 여러 주류 및 비주류 시스템에서 좋은 도구를 쓰지 말자고 하는 건 나쁜 방향으로 보입니다. 소프트웨어 개발 대부분이 64비트 플랫폼에서 이뤄지는데 32비트 타깃이 계속 자체 빌드를 해야 한다고 주장하는 것도 그렇습니다.
• @sunshowers — PEP 517의 요점이 어떤 도구로든 어떤 백엔드든 쓸 수 있다는 것이라면 Gentoo가 다른 빌드 백엔드를 가리키도록 패치를 적용하면 되지 않나요?
  • @nekopsykose — 그 말은 uv 빌드 프런트엔드를 쓰는 개발자가 flit-core든 uv-build든 원하는 백엔드를 선택해도 작동한다는 뜻입니다. 하지만 백엔드마다 암묵적인 동작과 설정이 다릅니다. 나중에 패키지를 빌드하는 사람이 자신이 선호하는 백엔드로 한 줄만 고쳐 바꾸기는 어렵습니다.
  • @sunshowers — 알겠습니다. 설명해 줘서 고맙습니다. 그래도 이 문제는 Gentoo만의 문제라고 생각합니다.
  • @jzb — Gentoo 사용자에게는 문제입니다. Rust가 없거나 uv-build를 빌드할 수 있는 Rust 구현이 없는 아키텍처를 지원하는 다른 Linux 배포판에도 정도는 덜하더라도 문제가 됩니다. 글에서 설명한 내용입니다.
• @moltonel — C 컴파일러만 작동하면 Python을 거의 어디서든 실행할 수 있다는 점이 얼마나 오래 유지될지 궁금합니다. Python 3.16에서 Rust를 쓰기 시작할 계획이 있습니다. 몇 버전 동안은 선택 사항으로 남겠지만 앞으로의 방향은 보입니다.
  • @masklinn — Gentoo도 이 사실을 알고 있습니다. PEP 사전 논의에서 이미 이 문제를 걱정했습니다.
• @mitsuhiko — uv-build에 순수 Python 대체 구현이 있으면 좋겠습니다. 현재 micropip 같은 일부 환경에서는 uv 빌드 백엔드를 사용할 수 없는 경우가 분명히 있습니다.
• @realkc — 빌드 성능 향상이 개발자에게만 이득이고 Gentoo 사용자에게는 손해라는 이유로 성능이 중요하지 않다고 보는 글쓴이의 주장에 동의하지 않습니다.
• @meghprkh — Termux에서도 비슷한 문제를 겪었습니다. Android용 휠이 보통 제공되지 않지만 추가 PyPI 인덱스를 설정하면 해결되는 경우도 있습니다. WebAssembly를 표준 사전 빌드 휠 아키텍처로 배포하면 호스트가 실행 환경을 제공하는 방식이 좋겠습니다. 모든 것을 소스에서 빌드하려는 Gentoo의 요구는 해결하지 못하지만 아키텍처 호환 문제와 샌드박스 처리되지 않은 바이너리 사용 문제는 줄일 수 있습니다.
  • @ubernostrum — PEP 783에서 이 방식이 표준화됐고 올해 4월 PyPI 지원도 들어갔습니다. 이미 WebAssembly 휠을 게시하는 패키지도 있습니다.
  • @mayli — 좋네요. 네이티브보다 느리지만 호환성이 훨씬 좋고 거의 어디서든 실행되는 휠이라니 멋집니다.
• @kornel — "rustix::fs와 그 의존성이 별다른 이유 없이 SPARC를 지원하지 않는다"는 대목은 이유가 있을지도 모릅니다. 테스트하려면 박물관에 가야 하니까요.

원문: Gentoo Blog / 번역·요약: Trawling