Я попробовал uv, обплевался и вернулся на poetry

Если вы последние полгода не читали чат, то вы не знаете, как сильно у меня горело после перехода на uv. Сейчас расскажу! Данный пост специально написан, чтобы и у вас тоже сгорело. Если к концу вы подойдете без боли в ... душе, то все было зря.

Как все было?

Обычно, я первый прыгаю пробовать все новые и модные штуки.
Так было с Pipenv, когда он только появился. Что там творилось!
Так было с poetry, которым я начал пользоваться через год, в 2018м.
Но вот с uv так не было, потому что я не знал, зачем бы мне хотелось переехать. Быстрее?

Но ладно, мы решили попробовать его на 3х проектах. Быстро же! Ух 🌚
- https://github.com/typeddjango/django-stubs (терпим)
- https://github.com/wemake-services/django-modern-rest (сложно съехать)
- https://github.com/wemake-services/wemake-django-template (откатили)

Почему?

Ох, даже не знаю с чего начать! Я напишу только про то, с чем столкнулся лично.

- У uv нет своей системы сборки для бинарников, uv_build умеет собирать только Python пакеты. DMR компилирует часть своих исходников, нам приходится доставлять hatch (другой пакетный менеджер), чтобы вообще иметь возможность работать. Топ кек
- Полное игнорирование стандартов. PEP 751? pip.conf? Нет, не слышали.
- uv публиковал нам сломанные README в PyPI, пришлось ставить плагин
- uv ставит вам совсем не тот питон, который вы думаете. pyenv ставит вам ровно то, что вы попросили, то uv тянет "relocatable" сборку: питон собранный на одной платформе для других платформ. Будет ли все работать? Конечно же нет. Сборка с ним пакетов локально просто не работает. Разбираться в C стектрейсе я не стал, просто поставил нужный питон через pyenv
- Сломанные дефолты. uv run автоматически ставит зависимости, что скрывало от нас баг в CI (нужно ставить UV_NO_SYNC=1. uv sync создает виртуально окружение без pip (нужно указывать UV_VENV_SEED=1), из-за чего pip install package ставит пакет в глобальный pip, даже с включенным venv. Ну то есть: вирутальное окружение начинает протекать :(
- Для шаблонов uv не подходит, потому что добавляет имя пакета в uv.lock (даже когда ты явно говоришь, что сам пакет ставить не надо), если оно меняется, то лок разваливается. Нам пришлось убрать параметризацию имени пакета в шаблоне. Потом откатили
- uv записывает текущую версию проекта (не пакета) в uv.lock, что ломает релиз тулы вроде semantic-release
- uv add package добавляет его в dependencies как "package>=current.version", что ломает будущие вызовы uv sync -U, когда к нам прилетают ломающие изменений из новых мажорных версий пакетов
- Нет возможности посмотреть устаревшие пакеты как в poetry show --outdated, есть внешний плагин
- Не работает uv sync без pyproject.toml, что нужно для кеша докер слоев. Уже джва года
- uv допускает дубликаты зависимостей с разными версиями (!), что вызвало у нас странный баг
- uv self update не работал в punq из-за наличия tox-uv в зависимостях
- uv не работает с dependabot, если используется workspace, пришлось переходить на renovate. PRов просто не было. uv sync -U с workspaces крайне плохо работает, какие-то пакеты приходилось руками обновлять
- Для продвижения ty добавили более длинный алиас uvx ty: uv check

Ну и самое главное: теперь uv принадлежит OpenAI. Можно ли им доверять важную часть инфраструктуры? Я сильно сомневаюсь.

Получил ли я что-то взамен на все мои новые страдания? Пример из wemake-django-template:
- poetry: 20 секунд
- uv: 11.4 секунды
Я понимаю, что для каких-то больших проектов разница может быть значительной.

Использовать? Если вы пофиксите дефолты у себя в конфиге, у вас стандартный проект, у вас есть линтер на номера версий, бот для обновления зависимостей, и вы реально замечаете время установки пакетов локально / в CI с другими тулами.

Ключевой вопрос: может стоило просто переписать резолвер и скачивание пакетов в poetry на rust?

Обсуждение: Какой ваш опыт? Заметили ли вы, что последнее время инструменты хайпят только за счет "скорости"?