uv vs Poetry в 2026 — стоит ли переезжать на новый стандарт?

[archmaster]

Веду несколько ML-проектов на Python, все на Poetry. Коллеги давно зудят что надо переходить на uv от Astral — дескать быстрее на порядок и скоро станет де-факто стандартом. Я пробовал uv на небольшом pet-проекте, в целом понравилось, но беспокоит совместимость с тяжёлыми зависимостями типа PyTorch, CUDA-пакетов и всего что связано с бинарными wheels. Кто уже мигрировал полноценные DS/ML проекты — какие грабли?

[burnedblueteam]

Мигрировал три проекта, один из них с torch+cuda+triton. Основная боль была с индексами: uv по умолчанию не знает про https://download.pytorch.org/whl/cu124 и нужно явно прописывать [[tool.uv.index]] в pyproject.toml. Как прописал — всё встало без проблем. Скорость установки окружения реально шокирует, особенно в CI: было 4 минуты, стало 25 секунд.

[vemina]

У меня другой опыт. Споткнулся на пакетах которые тянут кастомные системные библиотеки — libsndfile, ffmpeg-python и подобное. uv резолвер иногда выбирал не тот wheel и потом в рантайме падало. Poetry с этим справлялся лучше из-за более консервативной стратегии. Пришлось добавлять constraint файл.

[pandas4]

Для новых проектов беру uv без вопросов. Для старых — смотрю на размер: маленький, до 20 зависимостей — мигрирую, большой с кучей прибитых версий — оставляю Poetry, не трогаю работающее. Ещё uv inline scripts (uv run script.py с зависимостями прямо в файле) это отдельная магия для одноразовых задач.

[rwstanle]

Важная вещь которую многие упускают: uv lock и poetry.lock не взаимозаменяемы, нет инструмента автоконвертации с гарантией. Если в команде смешанный стек — придётся договариваться. У нас половина на uv, половина на conda (да, я знаю), регулярные конфликты при онбординге новых людей.

[sainty]

Про conda: uv теперь умеет работать с conda-окружениями через uv pip внутри активированного conda env. Это хороший компромисс если нужны conda-only пакеты (всякий специфичный биоинформатический стек) но хочется скорость uv для pip-зависимостей.