uv великолепен, но UX управления пакетами в нём

Кевин Ренскерс в заметке на loopwerk.io от 21 мая 2026 года: uv (инструментарий на Rust для Python от Astral) безоговорочно победил по скорости и объединил стек venv/pip/pyenv/pip-tools/poetry в один бинарник, однако команды для рутинного обслуживания проекта - то, что запускается еженедельно, а не в первый день, - слабее того, что Poetry и pnpm представили ещё годы назад. Аргументация строится на трёх конкретных пробелах в UX и одном проектном решении по умолчанию.

Нет отдельной команды outdated

Ближайший аналог pnpm outdated:

$ uv tree --outdated --depth 1

Она выводит всё дерево зависимостей целиком, а не фильтрует только устаревшие строки. Требуемое исправление - полноценная команда uv outdated.

Открытые границы версий по умолчанию

uv add pydantic прописывает "pydantic>=2.13.4" - без верхней границы. Последующий uv lock --upgrade в таком случае запросто подтянет pydantic 3.x или выше. pnpm по умолчанию использует ^1.23.4, а Poetry - >=1.23.4,<2.0.0. Оба варианта как минимум фиксируют мажорную версию.

Это решение из того же ряда, что каретка по умолчанию в Cargo и ^ в npm: большинство экосистем по умолчанию придерживаются принципа соблюдения SemVer для верхней границы. Ренскерс считает выбранное в uv поведение по умолчанию более рискованным для поставки, учитывая, как много проектов не проверяют diff'ы своих lockfile'ов регулярно. Подробнее о самой концепции - в default-version-bound-constraints.

Флаг --bounds major уже существует в режиме preview:

$ uv add pydantic --bounds major

в результате получается pydantic>=2.13.4,<3.0.0. Но его всё ещё нужно включать явно, и он помечен как preview.

Непоследовательный глагол для обновления

Чтобы обновить всё:

$ uv lock --upgrade

Здесь две претензии. Во-первых, очевидным глаголом верхнего уровня были бы uv update или uv upgrade. Во-вторых, CLI внутренне непоследователен: uv add и uv remove - это команды верхнего уровня, но симметричных uv lock --add или uv lock --remove нет, так почему же upgrade находится внутри uv lock?

Избыточный синтаксис при обновлении отдельных пакетов

$ uv lock --upgrade-package pydantic --upgrade-package httpx --upgrade-package uvicorn

Для сравнения:

$ pnpm update pydantic httpx uvicorn

Повторение флага становится громоздким, когда нужно выборочно обновить полдюжины пакетов.

К чему всё сводится

Автор не призывает отказываться от uv: скорость и единый инструментарий слишком ценны. Его тезис уже: uv стал новым стандартом по умолчанию для новых проектов, но его команды сопровождения пока не догнали предыдущее поколение инструментов. В частности, отсутствие верхней границы по умолчанию - это решение, которое годами будет незаметно ломать сборки, если его не исправить до того, как база пользователей uv окончательно закрепится на нём.

Текст полезно читать вместе с open-source-security-astral, где описаны строгие практики Astral по защите цепочки поставок для собственных релизов: контраст (строгость к своим релизам и мягкие ограничения по умолчанию для зависимостей конечных пользователей) делает эту публикацию особенно примечательной.

См. также

loopwerk-blog - блог-источник
default-version-bound-constraints - концепция ограничений верхней границы версий по умолчанию в npm/Cargo/Poetry/uv
open-source-security-astral - подход Astral к безопасности цепочки поставок; упоминается встроенная в uv поддержка cooldown
python-build-standalone - сторона дистрибуции того же набора инструментов: что именно скачивает uv python install
if-ai-writes-your-code-why-use-python - заметка Митчема упоминает поглощение Astral компанией OpenAI (март 2026 года) и то, что uv экономит Codex ~1 млн минут вычислений в неделю (контекст того, почему внедрение uv идёт так быстро)

uv великолепен, но UX управления пакетами в нём - полный хаос