Год с uv — инструментом управления Python-проектами: плюсы, минусы и стоит ли переходить

(Внимание, это длинная статья. Я увлёкся.)

После года использования uv, нового инструмента для управления Python‑проектами от Astral, с множеством клиентов, я понял, в чём его плюсы и минусы.

Если вкратце, мой вывод таков: если ситуация позволяет, всегда пробуйте сначала uv. Если он не подойдёт — переходите к чему‑то другому.

Это решение по принципу Парето: проще один раз попробовать uv, чем долго разбираться в других вариантах — и вы вряд ли пожалеете. Действительно, стоимость перехода на uv и обратно низка, но ценность, которую он приносит, довольно велика.

В этой статье я подробно разберу, почему это так. Также будет специальный раздел о случаях, когда не стоит использовать uv. Однако эта статья НЕ о том, как использовать uv. Об этом я напишу несколько позже отдельно.

---

Почему я так долго не делился своими выводами

Несмотря на мой энтузиазм по поводу uv, я придерживался позиции, что не могу рекомендовать его до того, как не попробую его в разных контекстах на практике.

Дело в том, что Python‑сообщество — огромное и разнообразное. В нём есть студенты, дата‑сайентисты, разработчики ИИ, веб‑разработчики, системные администраторы, биологи, географы, авторы плагинов... Они могут работать в университетах, в администрации, в стартапах, в армии, в лабораториях или в крупных корпорациях.

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

Это совсем другая ситуация, нежели чем, скажем, с PHP, JavaScript, Java или Ruby. Сравнительно мало людей создают плагин для X‑plane на Java, пишут скрипт для ГИС на Ruby, разрабатывают банкинговую систему на JavaScript или создают последнюю LLM модель с использованием PHP. Всё это можно делать с этими языками, но я видел намного больше сделанного на Python.

Будучи фрилансером и тренером, я регулярно погружаюсь в эти воды и видел, как все другие инструменты терпели неудачи. pyenv, poetry, pipenv, pdm, pyflow, pipx, anaconda…

Мой блог стал популярным после одной статьи: Почему бы не сказать людям «просто» использовать pyenv, poetry, pipx или anaconda.

Поэтому я не хотел давать ложные надежды людям и продавать им что‑то, что будет работать только в моём «пузыре», как, к сожалению, часто делают многие гики.

Теперь, когда я увидел, каков uv в использовании и как он ведёт себя в случае сбоев, я могу не только сказать вам, что стоит его использовать, но и объяснить, почему.

Но, конечно, я также могу рассказать, когда не стоит его использовать.

Какие проблемы пытается решить uv

Повторюсь, но бутстрапинг в Python — корень всех бед. Под бутстрапингом я имею в виду установку самого Python и конфигурацию нового проекта, чтобы в дальнейшем можно было устанавливать зависимости или собирать дистрибутив проекта. Большинство проблем, с которыми вы сталкиваетесь позже (например, при упаковке), на самом деле начинаются именно с этого.

Вот почему:

• Есть множество способов установить Python — с разными настройками по умолчанию и подводными камнями. И они различаются в зависимости от ОС.

• Нужно знать слишком многое заранее, чтобы просто установить Python — язык, который, по задумке, идеально подходит новичкам, а новички по определению этого не знают.

• Python используется в столь разных контекстах, что невозможно создать «универсальное руководство для всех». Опыт работы с Python на заблокированном корпоративном Windows и на Debian‑ноутбуке энтузиаста — это два разных мира.

• Очень немногие дают по‑настоящему полезные советы по этой теме, зато абсолютно каждый (включая их котов) говорит об этом с авторитетным тоном. В интернете. Слишком. Много. Чуши. По. Этому. Вопросу.

• Существует множество инструментов, которые пытаются решить эту проблему — и в итоге мы страдаем от паралича выбора.

• PATH, PYTHONPATH, ужасные соглашения об именовании, несколько версий Python на одной машине, необязательные пакеты в Linux и тот факт, что Python является системной зависимостью — всё это создаёт тысячу и один способ выстрелить себе в ногу.

• ‑m и py не справились со своей задачей. Большинство людей даже не знают, что они существуют.

• Популярность компилируемых расширений только добавляет хаоса в и без того сложную картину.

• Люди будут сталкиваться с проблемами, напрямую связанными со всем этим, но не понимая причин, просто скажут: «у Python ужасный пакетинг», — потому что будут винить инструмент, с которым они работали, а не настоящую причину, о которой они ничего не знают.

Таким образом, хороший инструмент управления Python‑проектами должен обладать следующими свойствами:

• Быть независимым от бутстрапинга Python, чтобы избежать проблем «курица или яйцо», а также обойти проблемы с PATH и PYTHONPATH.

• Уметь устанавливать и запускать Python единообразно и с предсказуемым поведением во всех ситуациях и на всех платформах

• Обеспечивать мост между базовыми инструментами (pip и venv) и собой.

• Обладать мощным разрешителем зависимостей.

• Делать простые вещи простыми (установка библиотек) и сложные вещи возможными (установка зафиксированных зависимостей под другую ОС, отличную от ОС разработчика).

• При этом быть простым в установке и использовании, и, конечно, настолько надёжным, чтобы вы могли доверить ему одну из наиболее важных частей вашего стека.

Ну а в чём, собственно, проблема?

Правильный бутстрапинг

Идея uv — гениальна. Всё, я сказал это.

И это не случайность — за этим стоит кропотливая работа талантливой и трудолюбивой команды Astral.

Во‑первых, они сделали uv полностью независимым от самого Python. Установка и обновление uv никак не влияют на установку и обновление Python. Ни одна проблема с бутстрапингом, PATH или импортом не может повлиять на uv.

В результате не нужно хорошо разбираться в экосистеме Python, чтобы установить uv. Нет путаницы — куда его ставить (в систему? в виртуальное окружение?) и как на него повлияет появление нового ключевого слова или устаревание чего‑либо.

Затем они начали с предоставления интерфейса к pip и venv, чтобы вы могли работать со своими текущими проектами, инструментами и рабочими подходами. Это недооценённое преимущество uv. Оно не только облегчает переход и снижает страх перед новизной, но ещё и:

• Показывает, что Astral уважает существующее сообщество.

• Признаёт важность огромного объёма legacy‑кода, накопленного в мире.

• Демонстрирует их готовность взять на себя стоимость поддержки всего этого технического наследия, накопленного годами.

Для меня это был сигнал: «Мы знаем своё сообщество и серьёзно настроены».

А ещё это значит, что вы можете использовать uv так же, как использовали раньше pip и venv (и даже pip‑tools), при этом вам никогда не нужно будет изучать команды uv run, uv add или uvx. Только за надёжность и скорость базовых задач переход уже себя окупает — ведь это тот же рабочий процесс, только быстрее и с меньшим количеством багов.

Даже если бы они остановились на этом — uv уже был бы полезным. Но, конечно, не остановились.

Они добавили способ установки самого Python:

• Унифицированный на всех ОС

• Без прав администратора

• Независимо от системы

• Без конфликтов при установке нескольких версий

• С одинаковой стандартной библиотекой (да, tkinter везде!)

• С поддержкой версий Pypy, No‑GIL и TCO (!)

• Без прослоек (shim'ов), без компиляции, с адекватными настройками по умолчанию

Пока я писал эту часть статьи, я установил pypy3.8 через uv за несколько секунд. Я даже не помнил, как это делается, но API и help‑сообщения были настолько понятны, что я быстро разобрался — и вот, у меня уже новая версия Python на машине:

❯ uv python list
cpython-3.14.0a4+freethreaded-linux-x86_64-gnu    <download available>
cpython-3.14.0a4-linux-x86_64-gnu                 <download available>
cpython-3.13.1+freethreaded-linux-x86_64-gnu      <download available>
cpython-3.13.1-linux-x86_64-gnu                   /usr/bin/python3.13
cpython-3.13.1-linux-x86_64-gnu                   /bin/python3.13
...
cpython-3.8.20-linux-x86_64-gnu                   <download available>
cpython-3.7.9-linux-x86_64-gnu                    /home/user/.local/share/uv/python/cpython-3.7.9-linux-x86_64-gnu/bin/python3.7 -> python3.7m
pypy-3.10.14-linux-x86_64-gnu                     <download available>
pypy-3.9.19-linux-x86_64-gnu                      <download available>
pypy-3.8.16-linux-x86_64-gnu                      /home/user/.local/share/uv/python/pypy-3.8.16-linux-x86_64-gnu/bin/pypy3.8 -> pypy3
pypy-3.7.13-linux-x86_64-gnu                      /home/user/.local/share/uv/python/pypy-3.7.13-linux-x86_64-gnu/bin/pypy3.7 -> pypy3

❯ uv python install pypy3.8
Installed Python 3.8.16 in 2.71s
 + pypy-3.8.16-linux-x86_64-gnu

❯ uvx -p pypy3.8 python
Python 3.8.16 (a9dbdca6fc3286b0addd2240f11d97d8e8de187a, Dec 29 2022, 11:45:13)
[PyPy 7.3.11 with GCC 10.2.1 20210130 (Red Hat 10.2.1-11)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>> import tkinter
>>>> import zipfile
>>>> import ssl
>>>>

На экране появилось сообщение: «Установлен Python 3.8.16 за 2.71 секунды». Всего 2.71 секунды! И я могу сделать то же самое и запустить его точно так же на Mac или Windows. Это впечатляет.

Никаких отсутствующих пакетов вроде Tcl, OpenSSL или Gzip. Никаких конфликтов с другими источниками Python. Не нужно использовать разные подходы для каждой операционной системы. Никаких недостающих команд или криво прописанных переменных PATH.

И всё это работает, потому что Astral использовали потенциал очень перспективного проекта — python‑build‑standalone, а затем взяли проект на сопровождение. Это сборки Python, которые работают без установщиков. Команда не только значительно улучшила проект, но теперь активно старается передать эти наработки обратно в основной репозиторий CPython. В течение всего проекта они демонстрировали свою приверженность развитию смежных open‑source проектов.

Нет, они мне не платят, честно!

Полезные функции управления проектами

Разумеется, они также добавили в uv расширенные возможности управления проектами, выходящие за рамки pip и venv. Эти функции являются опциональными, так что вы можете внедрять их поэтапно, в своём темпе.

• Команда uv init создаёт не только виртуальное окружение.venv, но и pyproject.toml, репозиторий Git (с.gitignore, настроенный под Python), README.md и hello.py по умолчанию. Всё это, конечно, настраивается.

• Корневые зависимости можно указывать прямо в pyproject.toml или добавлять их через uv add.

• Команда uv remove действительно корректно удаляет зависимости из проекта.

• С помощью uv lock ‑upgrade‑package <пакет>==<версия> можно обновлять пакеты аккуратно, по одной версии за раз.

• uv build создаёт .whl‑пакет из вашего проекта, при этом uv не требует, чтобы проект был полностью пригоден для сборки.

• uv run запускает любую команду внутри виртуального окружения — даже без его активации. Вам даже не нужно знать, что это окружение существует, или что значит его «активировать».

• Все эти команды автоматически и прозрачно обновляют lock‑файл. Вам не нужно вручную следить за состоянием проекта — всё происходит автоматически. Это возможно благодаря тому, что uv настолько быстрый, что вы даже не заметите момента обновления. Вам даже не обязательно знать, что такое lock‑файл.

• Lock‑файл работает кроссплатформенно (само по себе уже безумный факт!), так что вы можете разрабатывать на Windows, а деплоить на Linux.

Потрясающая производительность (что, кстати, не случайность — у Astral есть интересные приёмы для ускорения работы, подробнее в нашем интервью) означает не только то, что всё будет работать без усилий, но и то, что вам захочется экспериментировать. Больше не придётся платить ценой времени за попытки — вы всегда можете начать заново всего за несколько секунд.

Последний, но не менее важный момент — надёжность инструмента. Я даже не могу сосчитать, сколько раз pyenv, pipenv или poetry ломались у меня, вываливая длинный стек‑трейс. Поклонники этих инструментов скажут вам, что с ними такого не случается, но, во‑первых, они лукавят (я слышал это буквально за минуту до того, как инструмент выдал ошибку!), а во‑вторых, они обычно используют эти инструменты только в одном‑двух сценариях, что даёт им крайне ограниченное представление о ситуации.

С uv всё иначе — он оказался не просто надёжным, а ещё и обладает тремя крайне редкими и ценными качествами:

• Astral прекрасно чинят баги. Они действительно прислушиваются к обратной связи. Быстро реагируют на баг‑репорты. И они просто невероятно трудолюбивы. Их баг‑трекер — это отдельный повод для восхищения.

• У них отличная культура тестирования. Например, у них мощнейший набор тестов для проверки разрешения зависимостей. И они даже вынесли его в отдельный пакет, чтобы другие проекты тоже могли им пользоваться.

• Они делают прекрасные сообщения об ошибках. Посмотрите, как выглядит сообщение о сбое разрешения зависимостей:

❯ uv add httpie==2
  × No solution found when resolving dependencies for split (python_full_version >= '3.10'):
  ╰─▶ Because httpie==2.0.0 depends on requests>=2.22.0 and your project depends on httpie==2, we can conclude that your project depends on requests>=2.22.0.
      And because your project depends on requests==1, we can conclude that your project's requirements are unsatisfiable.
  help: If you want to add the package regardless of the failed resolution, provide the `--frozen` flag to skip locking and syncing.

Можно утверждать, что это заслуга pubgrub, но все их сообщения об ошибках похожи на этот пример, и они сознательно выбирают свои зависимости.

По сути, они взяли всё, что работало в pip, rye и poetry, и отказались от всего, что не работало. Затем они потратили месяцы, исправляя баги, чтобы довести продукт до безумно высокого уровня качества.

Это невозможно недооценить, поскольку такой уровень качества и преданности делу — крайне редкие явления в мире программного обеспечения. Обычно я ассоциирую их с такими продуктами, как VLC или SQLite. Вот к какой лиге я отношу uv.

Результат таков, что когда я передал uv своим студентам на тренингах, мне почти не пришлось вмешиваться. Я был удивлён, как быстро они начали работать продуктивно с этим инструментом, без особого вмешательства с моей стороны. Такое редко случается с любыми другими инструментами.

В профессиональных проектах всё было немного иначе. Новые проекты легко получали пользу от uv. А вот с наследуемыми проектами могли возникать проблемы, о которых мы поговорим позже.

Больше, чем вы ожидали

Вы, наверное, думаете, что я закончил восхвалять то, что на первый взгляд кажется просто усовершенствованным менеджером зависимостей, но у меня есть ещё несколько замечаний.

Создавая uv, Astral разработала сильные, быстрые и надёжные примитивы. И здесь вы открываете целую новую вселенную вариантов использования.

И это случилось.

В данном случае примитивы — это установка и изоляция Python и зависимостей.

Это может не звучать как нечто грандиозное, но на самом деле это смена парадигмы. Раньше я воспринимал это как ограничения. Что‑то, что мне нужно было сделать, что могло пойти не так, что было медленно и требовало осторожности, чтобы добраться до интересной части.

Но теперь с uv я воспринимаю это как возможности: я могу экспериментировать с ними, чтобы настроить свой рабочий процесс под себя.

Я написал целую статью про интересные приёмы с uv, но чтобы проиллюстрировать свою мысль, приведу два из них:

• Команда uv run ‑with jupyter jupyter notebook запустит Jupyter в текущем проекте... без добавления Jupyter и его зависимостей в проект! И благодаря тому, как работает кеширование в uv, последующие вызовы будут быстрыми.

• Хотите узнать, как ведёт себя pendulum при импорте в новой версии Python без GIL? Я только что выполнил команду uvx ‑with pendulum ‑p 3.13t python. Она скачала новую версию Python, установила её, создала временное виртуальное окружение, установила pendulum в него и запустила интерпретатор Python. Всё это произошло за несколько секунд. Затем я вышел — и всё исчезло.

Это то, что кардинально меняет рабочий процесс. Раньше у меня был один большой тестовый venv, который я регулярно удалял. Я избегал тестировать некоторые вещи, потому что это было слишком утомительно. Избегал использования некоторых инструментов или платил за это цену, потому что они занимали слишком много места или не были полезны настолько, чтобы оправдать настройку. И так далее.

uv, неожиданно для меня, принёс больше, чем просто управление проектами на Python. Он добавил uvx — программу, похожую на npx, для Python, которую я рассматриваю как «сделанный правильно pipx». Но он также добавил поддержку встроенных зависимостей, что в сочетании с другими возможностями uv (помните о хороших примитивах?) кардинально меняет способ работы с Python‑скриптами.

Раньше приходилось либо избегать зависимостей в небольших Python‑скриптах, либо использовать громоздкие обходные пути, чтобы заставить их работать. Лично я управлял гигантским виртуальным окружением (venv) только для своих локальных скриптов, которое мне приходилось удалять и очищать каждый год.

Теперь вы можете использовать что угодно. Это быстро. Прозрачно. Эффективно. И понятно без лишних пояснений.

Поскольку все эти вещи не навязчивы и необязательны, вы можете открыть их для себя и использовать в своё время. И я уверен, что со временем сообщество откроет всё больше и больше способов комбинировать эти возможности.

Когда uv не работает

Я вёл список недостатков uv в течение года, специально для этой статьи. Но этот список становился всё короче, так как Astral изо дня в день разбирал свой баг‑трекер. Они добавили редактируемые установки, резервную версию Python для команды uv run, доступный повсюду tkinter, поддержку неупакованных проектов, соблюдение XDG, отправку заголовочных файлов (да, это так!) и так далее. Они даже работают над поддержкой задач, пока вы читаете.

Так что жаловаться почти не на что, но я должен упомянуть об этом.

Иронично, но uv не решает проблемы с упаковкой. Реальные проблемы с упаковкой, а не последствия нарушенного бутстрепинга. Такие как неправильные метки версий, отсутствие «wheels», конфликты имён и т. д. Это потому, что это выходит за рамки контроля uv и связано с качеством данных, доступных на PyPI. Единственная причина, по которой вы увидите намного меньше проблем с упаковкой в uv — это то, что он делает всё остальное правильно.

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

Однако из‑за того, что в uv используется гораздо более строгий разрешатель зависимостей, он может «сломать» виртуальное окружение в устаревших проектах, где раньше использовалась старая версия pip с более мягким подходом к разрешению зависимостей.

У меня был друг, который решил не использовать uv, потому что при первом его использовании он работал с 15-летним кодом, который только что был мигрирован на Python 3. Он был основан на огромном количестве экспорта из pip freeze, который никто никогда не чистил.

Ещё одна проблема — поскольку uv использует python‑build‑standalone, вы ограничены версиями Python, которые были построены для этого формата. Хотя вы можете установить гораздо больше версий Python с помощью установщика с python.org, используя deadsnake или pyenv. Это не кажется проблемой для нового проекта, но для проекта, который работает долгое время и нуждается в одной конкретной версии Python, это может оказаться ограничением. К счастью, uv не возражает против использования установленной версии Python извне, так что это не такая уж большая проблема, но люди могут не осознавать это.

Тем не менее, это важная возможность, если вы хотите заменить версию Python на более быструю. Исполняемые файлы python‑build‑standalone немного медленнее (я только что провёл тест с pyperformance, и 3.10 от uv на 3% медленнее, чем мой Ubuntu), а также возможно, что однажды вы захотите использовать Python, скомпилированный с оптимизациями для вашего оборудования. Это не часто бывает необходимо, но неплохая опция для тех, кто хочет её использовать.

Да, я придираюсь на этом этапе.

Ещё одна проблема — сколько места занимает кеш uv. После года использования он занял более 20 ГБ на моём диске. Вы можете удалить его с помощью команды uv cache clean, но в этом случае вы потеряете невероятное преимущество скорости, которое он даёт.

Опять же, это не страшная проблема. У меня на жёстком диске 2 ТБ. Кроме того, место, занимаемое uv, скорее всего, будет меньше, чем все виртуальные окружения, которые я использовал раньше, поскольку, в отличие от pip, пакеты устанавливаются с использованием жёстких ссылок и занимают место только один раз.

У меня есть ещё одна мелкая проблема: переменная $UV_PYTHON заставляет использовать конкретную версию Python, вместо того чтобы предоставлять вам версию по умолчанию. Но это уже было решено.

Очевидно, что я должен также коснуться проблемы, которая лежит на поверхности: uv — это коммерческий продукт компании Astral. Несмотря на то, что он с открытым исходным кодом, и как бы великолепна ни была Astral, вам придётся доверять, что они будут поддерживать его доступность и актуальность. Более того, компания пока не прибыльна, мы не видели от неё коммерческих предложений, так что мы не знаем, что будет дальше. Некоторые люди, как в нашем интервью с Расселом Кит‑Мэги, начинают нервничать и утверждают, что мы должны быть осторожны, прежде чем передавать управление такой важной частью нашего стека.

Лично я не переживаю по этому поводу. Миграция на uv была лёгкой почти во всех проектах, с которыми я работал, и миграция обратно тоже не является проблемой. Больно, потому что приходится прощаться с потрясающими возможностями, но не сложно. К тому же, Astral накопила огромное количество доверия благодаря своему безупречному поведению, так что если мне нужно доверить это кому‑то, я предпочёл бы довериться им. Я даже приветствую появление платного продукта, хочу отдать им деньги. Хочу, чтобы они процветали.

Это open‑source, любой может форкать. Не говоря уже о том, что код невероятно чистый. И да, это Rust, но сейчас есть немало питонистов, которые знают Rust. Я вполне уверен, что если Чарли собъёт автобус, Армин или кто‑то другой сразу же вмешается.

Нет, на сегодняшний день самое большое ограничение в использовании uv — это корпоративное внедрение. В крупных, защищённых и ограниченных корпоративных средах установить новые зависимости чрезвычайно сложно. Сейчас, если у вас есть IT‑отдел по безопасности, который регулирует, что можно и что нельзя делать на вашем устройстве, они не позволят вам установить uv. До тех пор, пока он не станет стабильной версией и не пройдёт все необходимые проверки.

Однако я предполагаю, что именно так Astral собирается зарабатывать деньги, конкурируя напрямую с Anaconda. И уверяю вас, для этого существует спрос, потому что Anaconda — это полная противоположность Бэтмену (то есть не герой, а скорее антагонист в вашей системе), и если им удастся решить вопрос с лоббированием, техническая сторона уже будет хвалить uv с самого начала.

Но если они действительно хотят этого добиться, им нужно решить ещё одну проблему: есть немалая группа Python‑разработчиков, которые не чувствуют себя уверенно в командной строке. Особенно это касается Windows, то есть большинства корпоративного рынка. Вот почему у Anaconda есть графический интерфейс. Это одна из причин, почему я рекомендую установщики с python.org. Требовать от начинающих использовать CLI‑инструмент — значит создавать входной барьер.

Наконец, uvx (а следовательно и uv tool install) страдает от проблемы, схожей с pipx, так как он поощряет установку некоторых инструментов вне вашего проекта. Это имеет смысл для таких инструментов, как yt‑dlp или httpie, которые являются самостоятельными независимыми инструментами. Но это ловушка для dev‑инструментов, которые зависят от синтаксиса или библиотек, например, mypy, который будет установлен для одной версии Python, а затем использоваться на проекте с другой, потенциально несовместимой версией. Это приведёт к поломке, и многие пользователи не поймут причину сбоя.

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

Итак, когда стоит использовать uv, а когда нет? 

В общем, есть 5 ситуаций, когда не стоит использовать uv:

1. У вас старый проект, в котором uv не сможет корректно разрешить зависимости, и вы не можете (или не хотите) привести всё в порядок для миграции.

2. Вы находитесь в корпоративной среде, которая не позволит вам использовать его.

3. Вы пока не доверяете этому инструменту, потому что это нестабильная версия, потому что Astral не выпустила коммерческое предложение, потому что сообщество Rust‑контрибьюторов слишком небольшое и т. д.

4. Вам нужна конкретная версия Python, которой нет в uv, и вы не хотите использовать uv, если не можете установить Python с его помощью, несмотря на то, что он отлично работает с Python, установленным сторонними средствами.

5. Вы считаете, что командная строка — это слишком большая преграда для команды.

Для меня 3 и 4 пункты не являются техническими, это скорее выбор. Я не пытаюсь убедить вас в том, чтобы сделать другой выбор, у меня нет личных интересов в этом вопросе — делайте, как считаете нужным.

Пункт 2 — это то, что вы не можете изменить, так что этот момент не обсуждается.

Это значит, что на самом деле мне стоит рассматривать только пункты 1 и 5, и для этого у меня есть один единственный совет:

Всегда сначалапробуйте uv. Если он не сработает (что бывает очень редко), возвращайтесь к тому, что было раньше, или ищите обходное решение.

Если командная строка станет слишком большой проблемой, предложите использовать установщик python.org для установки Python и плагин IDE, который абстрагирует uv. Но для начала попробуйте. Люди, которые могут программировать, обычно могут освоить базовые команды в командной строке, чтобы использовать uv.

Если это действительно не сработает, переходите к чему‑то другому.

Что дальше?

До выхода версии 1.0 в uv ещё остаются отдельные недоработки, и это требование для корпоративного будущего, так как в таких условиях обновления не всегда возможны. Я предполагаю, что в инструмент будет добавлена какая‑то форма бандлинга как альтернатива pex/shiv, а также, возможно, бэкэнд для сборки. Не знаю, есть ли у них планы по созданию установщика для вашего приложения, но это будет логичное продолжение, хотя это гораздо сложнее, чем может показаться (одни только подписи — это уже сложно).

Я постоянно запускаю команду uv self update, чтобы получить новые функции, которые они постоянно добавляют, но если честно, когда они доведут историю с задачами до ума, инструмент будет полностью покрывать мои потребности.

В любом случае, я собираюсь отредактировать все свои статьи о pip и venv, чтобы упомянуть uv. И написать туториал по uv.

Тем не менее, всё равно стоит уметь работать с pip и venv, если Python — это ваша работа, потому что, вероятно, вы окажетесь в ситуации, когда uv не будет доступен.

Но, начиная с этого момента, я буду говорить всем «просто используйте uv».

---

Материал подготовлен в рамках специализации "Python Developer". На странице курса можно ознакомиться с подробной программой, а также записаться на открытые уроки.

А если вы хотите углубиться в вопросы, связанные с управлением проектами, инфраструктурой и современными практиками разработки, эти открытые уроки дадут вам полезные инструменты и практические знания для дальнейшего роста:

• Docker в действии: как контейнеризация меняет аналитику данных? — 24 апреля, 20:00

• Docker для инженера данных — 29 апреля, 20:00

• GitOps практики. Развертываем сервис через ArgoCD — 7 мая, 20:00