Комментарии 14
Всегда против тулз на языках, не совпадающих с целевым. Цикл отладки размыкается и разработчик лишается мгновенной обратной связи. Скорость для пакетного менеджера имеет значение только в CI/CD, это как раз горячая установка в которой отставание незначительно, и вряд ли является решающим тормозом в пайплайне. С другой стороны, разработчики на Rust не заинтересованы кровно в надёжности тулзы для разработчиков на Python, в отличие от poetry.
Никакого разделения на "разработчиков на Rust" и "разработчиков на Python" тут нет. Есть разработчики на Python и Rust. Python вообще никогда не был замкнутой на себе экосистемой.
а что там насчет NumPy и еще кучи питоновых либ, написанных на С?
У нас довольно большой проект десктопного приложения, который разбит на микросервисы (это позволяет нам разрабатывать модули и обновлять их независимо друг от друга). Изначально это был монолит, который мы успешно попилили. В процессе перехали с `pip install -r ...` на poetry. Пока модулей было 3-4 - все было нормально. Когда модулей стало 20+ резолв зависимостей время от времени начал занимать какое-то не адекватное количество времени. У нас в чате скидывали скрины с 3000+ секунд, на выполнение poetry update.
Мы некоторое время искали проблемы внутри (и они определенно были. Например бинарные файлы в репах). Исправили это. Но время на poetry update для проекта в который подключены все модули - 500-600 секунд запросто.
В тестовом формате добавили uv. Первый резолв долгий, около 120-150 секунд. Но дальше все стало сильно лучше 20-30 секунд и обновления уже загружены. И о чудо. Добавление конкретной ревизии модуля (по имени ветки или хэшу коммита) не растягивает общий резолв. Короче команда радуется, а я все ещё настороженно отношусь к продуктам с нулевой мажорной версией.
С CI\CD кстати в poetry не так больно, и разницы с uv - нет. Так как уже сформирован lock файл. Нет необходимости решать зависимости, просто берешь пакеты и устанавливаешь.
У вас poetry update частая операция? Я тоже над немаленьким проектом работаю, но мы обновляем зависимости только по веским причинам и редко сразу несколько: poetry lock --no-update реагирует только на изменённые в pyproject.toml версии.
У разработчиков не прям чтобы частая, но вот тестеровщики - очень даже, потому что им надо тестировать модули в составе продуктов.
Ещё раз обращаю внимание, что это не резолв внешних зависимостей, это модули нашего приложения. Внешние зависимости у нас тоже с фиксированными версиями и обновляются только при CVE или других критичных багфиксах
Любой инструмент либо вызывает боль на данный момент, либо нет. Если вам норм с poetry/pip, то переходить на uv нет смысла. Если у вас есть проблемы с uv, а pip/poetry их решает, то есть смысл перейти на pip/poetry. А все эти домыслы про то, что uv испортится в будущем(потому что на расте, потому делается сторонней фирмой и т.п.) точно также применимы и к poetry и к pip, pip по сути уже "испортился". Мы не знаем, что будет завтра, возможно pip переделают и он станет самым лучшим менджером в python. Свитчится придётся всё равно рано или поздно, т.к. мир меняется и появляются новые инструменты, которые вытесняют старые.
Автор, а вы можете сказать почему в кинотеатре где вы занимаетесь бэкендом нет обычных фильтров что бы можно было отфильтровать фильмы по жанру\году\стране?
poetry, uv всё это надстройки без которых можно обходиться. ориентироваться лучше на PEP 518 и PEP 621. у poetry есть существенный недостаток, он еще далек о стабильной версии и не стоит удивляться если после обновления у вас станут возникать ошибки.
По UV из статьи не понять как собирается пакет.
В целом статья с пробелами, да тема выбрана из разряда, есть плохое решение и еще одно, попробуем их сравнить по непонятным метрикам. Автору стоила заглянуть в исходники какой-либо библиотеки более или менее популярной (например fastapi, flask, numpy и т.д.), удивиться что там нет ни poetry, ни uv, изучить используемые технологии и написать хорошую статью.
https://github.com/fastapi/fastapi/blob/master/.github/workflows/test.yml
И uv и ruff в наличии, uv - это не сборщик. по крайней мере пока.
Flask уже давно не передовой с точки зрения прогресса продукт.
Numpy слишком тяжелый и специфичный проект и uv им последнюю очередь нужен.
И нет, без uv я уже жить не хочу. Это наверно лучше что было сделано для тулинга питона за последние несколько лет
Сделают еще тайпчекер внутри ruff я еще и pyright выкину.
https://github.com/fastapi/fastapi/blob/master/pyproject.toml
build-backend = "pdm.backend"
он еще далек о стабильной версии
У меня большие вопросы к инструменту, который достиг второй версии, но никак не может стабилизироваться.
Poetry vs UV: удобство или скорость?