Мейнтейнер Gentoo закликає розробників Python-проєктів припинити використання uv-build як бекенд

Заклик

Міхал Ґурні, розробник Gentoo, опублікував заклик, в якому просить мейнтейнерів пакетів Python не використовувати uv-build як бекенд для збірки. Він наголошує, що критика не стосується самого uv чи інших інструментів Astral, які він описує як хороші інструменти з добрим і відповідальним upstream. За його словами, проблема саме в бекенді uv-build, користь якого не перевищує його недоліки для таких downstream-дистрибутивів, як Gentoo. Він зазначає, що вже десятки пакетів Gentoo втратили keywords, бо одна з основних залежностей перейшла на uv-build.

Розмір і навантаження на збірку

Головна проблема в тому, що uv-build великий і написаний на Rust. Для версії 0.13.0 його wheels залежно від платформи коливаються від 1,2 МіБ до 1,5 МіБ, тоді як у flit-core, маленького чистого бекенда на Python, показник становить приблизно 45 КіБ. Оскільки Gentoo збирає пакети з джерела, кожен користувач має зібрати uv-build, а проєкт досить часто випускає нові версії: до написання статті за 30 днів було 12 релізів. Ґурні оцінює, що кожні 100 мс, які потрібні для запуску uv-build для встановлення одного релізу пакета, користувачі Gentoo сумарно витрачають багато годин на повторну збірку нових версій uv-build.

Проблеми з портовністю

Ґурні стверджує, що час збірки — не найбільша проблема, головна — портовність. Python може працювати майже всюди, де існує робочий C-компілятор, тоді як список платформ, що підтримуються Rust, повільно зростає. Навіть коли компілятор Rust доступний, uv може не працювати через різні проблеми: від помилок в залежностях, наприклад rustix::fs і його залежностей, що пропускають SPARC, до надто великих виконуваних файлів, на які toolchain не має достатньо адресного простору. В Gentoo ebuild для uv вже має два хаби, щоб uv збирався на 32-бітних платформах. Для платформ, які взагалі не підтримуються, додавання нової платформи та її підтримка вважається повною секцією, яка може вимагати багато зусиль через зміни в коді.

Аргументи на користь альтернатив

Ґурні визнає, що існує два аргументи на користь uv-build. Перший — узгодженість з використанням uv у проєкті, що він відкидає, оскільки PEP 517 передбачає, що будь-який бекенд працює з будь-яким frontend, тому flit-core або hatchling працюватиме з uv або будь-яким іншим інструментом без проблем. Другий — продуктивність, яка, за його словами, становить приблизно 100 мс для рідко виконуваної дії і може бути легко перекрита часом завантаження 1,5 МіБ wheel. Він робить висновок, що бекенд використовують лише розробники проєкту, конторибутори, CI/CD робочі потоки, створювачі downstream-пакетів та користувачі дистрибутивів джерела, тоді як звичайні користувачі використовують wheels. Серед цих груп користувачі дистрибутивів джерела є найбільшими й найбільше постраждалими, і будь-яка вигода продуктивності втрачається через час, витрачений на збірку uv-build.

Джерела: Lobsters