Gentoo 개발자, 순수 Python 패키지에 uv-build를 쓰지 말아 달라고 호소

개인적으로 기업의 이해관계에 좌우되는 구성 요소를 생태계의 핵심 의존성으로 삼는 데 반대함. 생태계는 자립할 수 있어야 하며, 기업은 생태계 전체를 지원하도록 조직된 곳이 아닌 만큼 이해관계가 언제든 바뀔 수 있음.

그러면 의존 소프트웨어의 선택지가 너무 좁아지지 않을까? Python, Django, PostgreSQL, Node.js처럼 단일 기업에 종속되지 않는 탄탄한 거버넌스를 갖춘 오픈 소스 프로젝트도 있지만, 그 수는 상당히 적은 편임.

uv 유지보수 담당자 중 한 명임. Python 패키징의 장점은 표준화되어 있다는 것으로, uv의 빌드 백엔드가 요구에 맞지 않으면 패키징 표준을 잘 준수하는 다른 백엔드를 선택할 수 있음.
다만 Gentoo가 uv-build의 모든 릴리스를 다시 빌드해야 하는 이유는 이해하기 어려움. uv-build는 uv 자체만큼 자주 바뀌지 않고, 의도적으로 여러 uv 버전과 호환되도록 설계됨. 중요한 호환성 파괴 변경이나 버그 수정만 예외로 두고, 일주일에 한 번 또는 그보다 드물게 업데이트하면 안 될까?
uv-build가 자주 출시되는 이유는 내부 코드를 uv의 나머지 부분과 함께 맞춰 관리하기가 더 쉽기 때문일 뿐임. Python 빌드 백엔드 메타데이터에 일반적인 버전 범위를 지정하면, uv는 이미 설치된 uv-build 버전을 그대로 사용할 수 있음.

Gentoo가 이렇게 빠르게 바뀌는 의존성에 어떤 정책을 적용하는지는 잘 모르겠음. uv-build가 uv에 묶여 있어 업데이트 주기를 줄이기 어려운 것인지도 궁금했지만, 확인해 보니 별도 패키지로 제공됨.
uv가 출시될 때마다 uv-build도 별도로 출시되니, 얼마나 자주 업데이트해야 하는지 불분명할 수 있음. 외부 패키지 관리자를 위해 며칠 간격으로만 업데이트해도 괜찮다는 공식 지침을 제공하면 도움이 될 듯함.

다른 빌드 백엔드의 설정 API도 작업에 따라 부족하거나 답답할 수 있다는 점은 빠져 있음. 예전에 hatchling에서 생성된 파일 중 .gitignore에 걸리는 파일을 패키지에 넣으려다 상당히 고생한 적이 있음.
그 밖에는 좋은 글이며, 배포판 패키지 관리자 관점에서 uv_build를 생각해 본 적은 없었음. Python 패키지가 배포판 저장소에 들어가야 한다는 데는 확신이 없지만, 그건 배포판 측이 결정할 일임.

이제는 옛 컴퓨터를 다루는 취미의 대상에 가까운 구형 CPU 지원이나, 소프트웨어 개발이 거의 모두 64비트 플랫폼에서 이뤄지는 시대에 32비트 대상의 자체 빌드 능력을 유지하려고 여러 주류·비주류 시스템에서 유용한 도구를 포기하자는 방향은 좋지 않아 보임.

PEP 517의 취지가 어떤 도구에서든 어떤 백엔드든 쓸 수 있게 하는 것이라면, Gentoo가 다른 빌드 백엔드를 가리키도록 패치하면 되지 않을까?

그 말은 개발자가 uv build 프런트엔드를 쓸 때 flit-core든 uv-build든 원하는 빌드 백엔드를 선택할 수 있다는 뜻임. 백엔드마다 암묵적 동작과 설정이 다를 수 있으므로, 나중에 프로젝트를 빌드하는 쪽에서 백엔드 지정 한 줄만 바꿔 원하는 백엔드로 전환하기는 보통 어려움.

작동하는 C 컴파일러만 있으면 거의 어디서든 Python을 실행할 수 있다는 특성이 얼마나 더 유지될지 궁금함. Python 3.16에서 Rust 사용을 시작할 계획이라면 몇 버전 동안은 선택 사항으로 남겠지만, 앞으로의 방향은 분명해 보임.

uv-build에 순수 Python 대체 구현이 있으면 좋겠음. 현재는 micropip처럼 uv 빌드 백엔드를 사용할 수 없는 환경이 분명히 존재함.

빌드 성능 개선은 개발자에게만 이롭고 Gentoo 사용자에게는 악영향을 주므로 빌드 성능은 중요하지 않다는 글쓴이의 생각에는 동의하기 어려움.

보통 Android용 wheel이 제공되지 않아 Termux에서도 비슷한 일을 겪곤 함. 다만 이를 위해 추가할 수 있는 별도의 PyPI 인덱스는 있음. WebAssembly를 표준 사전 빌드 wheel 아키텍처로 배포하고 호스트에서 런타임으로 실행할 수 있으면 정말 좋겠음. 모든 것을 소스로 빌드하려는 Gentoo의 요구까지 해결하지는 못하지만, 아키텍처 때문에 생기는 불편을 줄이고 샌드박스 밖에서 실행되는 바이너리를 쓰지 않아도 됨.

PEP 783에서 이를 공식화했으며, PyPI 지원은 올해 4월에 추가됨. 이미 WASM wheel을 배포하는 패키지도 있음.