Уникальная нотация языка UNO создаёт ему огромный потенциал, позволяющий в перспективе заменить большинство нынешних языков разметки данных.

Понятно, что XML и JSON имеют собственные ниши, в которых они могут находиться вечно, но существует огромный ряд задач, где даже их можно с выгодой заместить. Что же касается таких специализированных форматов, как TOML, YAML, KDL, HCL или EDN, то при повсеместном внедрении UNO они рискуют потерять свою актуальность. Из-за врожденных синтаксических недостатков, медленного парсинга или скрытых ошибок, обусловленных недостаточным проектированием, эти языки могут остаться лишь в легаси-проектах. Верно ли данное утверждение? Давайте разбираться.

Мы списали uv со счетов. А потом он ускорил наш CI на 80%

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

Мы так и сделали. Взяли один микросервис: Python 3.14, 37 прямых зависимостей, 153 пакета в lock-файле, приватные пакеты и внутренний Nexus. Ожидание было простым: если uv действительно быстрее Poetry, миграция окупится сама.

Локально получилось наоборот. Резолвинг — да, быстрее. Установка по готовому lock-файлу — нет, иногда даже медленнее. Эксперимент закрыли и остались на Poetry.

Через несколько недель пришлось вернуться. Не из любопытства, а из-за алерта Trivy и сюрпризов Poetry 2 с корпоративными индексами. И вот тогда uv показал себя совсем в другом месте — в CI.

В статье разберем:

- почему локальный бенчмарк uv vs Poetry нас обманул;
- как Poetry 2 сломал привычную разработку без VPN;
- зачем мы писали парсер poetry.lock → requirements.txt и почему это оказалось костылём;
- как точечная замена Poetry на uv sync в пайплайне сократила время с 5:10 до 2:50;
- почему в итоге uv стал единым стандартом и локально, и в CI.

Коротко: если инструмент не выиграл с первого прогона — это ещё не значит, что он бесполезен. Часто вы просто мерили не то узкое место.