Если вы последние полгода не читали чат, то вы не знаете, как сильно у меня горело после перехода на
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?
Обсуждение: Какой ваш опыт? Заметили ли вы, что последнее время инструменты хайпят только за счет "скорости"?
