Poetry, PDM или uv: выбираем менеджер зависимостей для команды

Команда из шести человек тратила по 40–90 секунд на пересборку окружения при каждом переключении ветки: Poetry заново резолвил зависимости после смены pyproject.toml. После перехода на uv та же операция стала занимать 1–3 секунды на прогретом кеше. Это не выдуманный рекорд из релиз-ноутов, а типичная разница между резолвером на чистом Python и резолвером на Rust — и один из аргументов в споре, который сейчас идёт в каждой второй Python-команде.

Разберём три инструмента — Poetry, PDM и uv — с точки зрения командной работы: воспроизводимость окружения, скорость, привязка к стандартам и цена миграции. Тема установки одного пакета на своей машине здесь не рассматривается — интересует, что происходит, когда над проектом работают несколько человек и CI.

Что именно решают эти инструменты

Все три закрывают три задачи разом, в отличие от связки pip + venv + requirements.txt:

• объявление зависимостей в pyproject.toml;
• резолвинг совместимого набора версий и запись его в lock-файл;
• создание и синхронизация виртуального окружения по этому lock-файлу.

Lock-файл — ключевой пункт для команды. Он фиксирует не только прямые зависимости, но и все транзитивные, с точными версиями и хешами. Именно он гарантирует, что у вас, у коллеги и в CI соберётся одинаковое окружение. Без него «у меня работает» превращается в диагноз.

Резолвинг зависимостей — процесс подбора версий всех пакетов так, чтобы их требования друг к другу не конфликтовали. Задача вычислительно тяжёлая: в худшем случае это перебор комбинаций, поэтому скорость резолвера заметно влияет на комфорт.

Три инструмента коротко

Poetry

Появился раньше остальных и стал де-факто стандартом для многих команд. Свой lock-файл (poetry.lock), своя логика управления окружениями, встроенная сборка и публикация пакетов. Долгое время Poetry использовал собственную секцию [tool.poetry] вместо стандартной [project] из PEP 621; поддержка [project] появилась в Poetry 2.0 (начало 2025 года). Резолвер написан на Python — отсюда основная жалоба на скорость на больших деревьях зависимостей.

PDM

Ставит во главу угол следование PEP: с самого начала работает со стандартной секцией [project], поддерживает PEP 582 (режим без явного venv, __pypackages__) как опцию. Гибкий, ближе к стандартам, чем Poetry, но менее распространён — меньше готовых рецептов и ответов на типовые проблемы.

uv

Самый молодой, от команды Astral (авторы линтера Ruff). Написан на Rust, за счёт этого установка и резолвинг быстрее на порядок в типичных сценариях. Умеет ещё и управлять версиями самого Python (скачивает нужный интерпретатор), заменяя pyenv. Развивается очень быстро — это и плюс, и риск: интерфейс и поведение между минорными версиями меняются чаще, чем у зрелого Poetry.

Скорость uv — не про «стало приятнее». Она меняет привычки: если пересборка окружения бесплатна, разработчик перестаёт бояться удалить venv и собрать заново — а это самый надёжный способ починить «поломанное непонятно чем» окружение.

Сравнение по параметрам, важным для команды

Lock-файлы у всех трёх несовместимы между собой и не читаются чужим инструментом. Это значит, что выбор — командное решение: смешивать нельзя, иначе воспроизводимость теряется.

Как выглядит работа на практике

Базовые сценарии похожи, различается синтаксис. Ниже — не полный референс, а типовой цикл: инициализация, добавление зависимости, синхронизация окружения по lock-файлу.

uv (версия 0.5.x и новее)

# создать проект и pyproject.toml
uv init myproject
cd myproject

# добавить зависимость — сразу обновит uv.lock
uv add requests

# добавить dev-зависимость в отдельную группу
uv add --dev pytest

# синхронизировать окружение строго по lock-файлу
# (то, что нужно запускать в CI и у коллег)
uv sync

# запустить команду внутри окружения
uv run pytest

Poetry (версия 2.x)

# создать проект
poetry new myproject
cd myproject

# добавить зависимость
poetry add requests

# добавить в группу dev
poetry add --group dev pytest

# установить строго по poetry.lock
poetry install

# запустить команду внутри окружения
poetry run pytest

PDM (версия 2.x)

# инициализировать проект
pdm init

# добавить зависимость
pdm add requests

# добавить в группу dev
pdm add -dG dev pytest

# установить по pdm.lock
pdm install

# запустить команду
pdm run pytest

Обратите внимание: в командном сценарии критична разница между «добавить пакет» (add) и «установить ровно то, что в lock» (sync/install). В CI и на машине коллеги нужен второй вариант — он не трогает lock-файл, а воспроизводит зафиксированное состояние. Если в CI случайно вызвать add или дать инструменту обновить lock, вы получите то самое «в CI собралось иначе».

Когда что выбирать

• Проект уже на Poetry, всё работает. Не мигрируйте без причины. Poetry 2.0 закрыл главную претензию по стандартам, а скорость на среднем проекте терпима. Миграция — это переучивание команды и переписывание CI, цена реальная.
• Новый проект, важна скорость и вы готовы к активным обновлениям. uv. Особенно если в команде уже есть боль с pyenv — uv заодно уберёт отдельный инструмент для управления версиями Python.
• Приоритет — соответствие PEP и гибкость, команда небольшая и опытная. PDM. Он предсказуемо следует стандартам, но будьте готовы реже находить готовые ответы на нестандартные проблемы.
• Монорепозиторий с несколькими пакетами. Смотрите на поддержку workspaces у конкретной версии инструмента — здесь реализации отличаются сильнее всего, и это стоит проверить по актуальной документации перед решением.

Что ломается

Типичные грабли, которые всплывают именно в команде, а не на одной машине:

• Lock-файл не закоммичен или в .gitignore. Тогда воспроизводимости нет вообще, и все преимущества этих инструментов над голым pip обнуляются. Lock-файл обязан быть в репозитории.
• В CI используется команда, обновляющая lock. Проверьте, что пайплайн вызывает именно синхронизацию по lock (uv sync, poetry install, pdm install), а не добавление или обновление.
• Разные версии самого инструмента у разных людей. uv, меняющийся быстро, особенно чувствителен: зафиксируйте версию инструмента (например, через отдельный шаг установки конкретной версии в CI и договорённость в команде).
• Ручная правка pyproject.toml без пересборки lock. После изменения зависимостей вручную lock-файл устаревает молча. Всегда обновляйте lock командой инструмента и коммитьте его вместе с pyproject.toml одним изменением.

Что делать дальше

Если выбираете для нового проекта — возьмите uv, соберите на нём CI-пайплайн из двух шагов (установка фиксированной версии uv, затем uv sync --frozen для проверки, что lock актуален) и прогоните на реальном дереве зависимостей. Замерьте время холодной и тёплой сборки в вашем CI — это единственная цифра, которая для вашей команды честная, в отличие от чужих бенчмарков.

Если думаете о миграции с Poetry — сначала проверьте, поддерживает ли ваш деплой и внутренние индексы пакетов новый инструмент, и только потом переводите один некритичный сервис. Флаг --frozen (или его аналог) для проверки актуальности lock в CI смотрите в документации выбранной версии: точное имя и поведение между релизами уточняйте там.