Комментарии 4
Какой-то огромный набор велосипедов, а в результате никуда и не поехали...
Не понял, зачем нужен direnv, если потом всё равно делается самопальный скрипт, который может ровно так же сразу и окружение импортировать - вместе с проверками три строчки кода добавится.
А так вас Pyenv + UV + direnv + самописный скрипт импорта окружения (!!!), и все рулят виртуальными окружениями (!!!). Несколько... странно? Один из велосипедов и вовсе из исходников собран - вот радость для продакшена будет! Неужели такой необходимый велосипед?
Даже make прикручен, фигачили бы уже сразу scons какой-нибудь, чтобы уже прямо вообще.
А потом весь этот зоопарк велосипедов нужно будет прикрутить к IDE. А потом к продакшену.
А сверху ещё и nginx прикрутить придётся, так как веб-сервер не поддерживает HTTP3/QUICK.
И что интересно, при всём богатстве велосипедов, в реальность поставить несколько версий Python под Linux всё равно будет больно и сложно. На всех велосипедах заявлена установка и поддержка нескольких версий компиляторов, но где вы в реальности эти версии возьмёте? А если вы их уже взяли, то вон в тот скриптовый файл нужно просто ещё две переменные окружения добавить и больше ничего не нужно.
Может быть, я конечно и придираюсь и сейчас так принято, но как-то это всё так себе выглядит. Ощущение, что каждый последующий велосипед изобретал человек, который толком не разобрался в предыдущем, и которому было просто лень написать скрипт в пять строк. И потому он с энтузиазмом ваялся ещё один велосипед с очередной собственной поддержкой "виртуальных окружений" и "нескольких версий интерпретаторов". Киллер-фичи прямо.
Добрый день, прошу прощенья, что долго не мог ответить. Благодарю за такой подробный и вдумчивый комментарий — это правда здорово, что вы так глубоко погрузились в статью и поделились своими мыслями!
Давайте разберём всё по порядку, и я с радостью отвечу на ваши вопросы, а заодно попрошу у вас совета — вдруг вы подскажете что-то, что я упустил.
Вы абсолютно правы, что набор инструментов может показаться избыточным — и это прекрасный повод для диалога! Я выбирал их с прицелом на эксперимент: попробовать что-то новое, посмотреть, как это работает в связке, и поделиться впечатлениями с читателями. Например, direnv я взял, чтобы автоматизировать активацию окружения без лишних действий — заходишь в папку, и всё само подхватывается. Но вы верно заметили, что скрипт в .envrc можно было бы упростить или вообще обойтись без него, добавив пару строк в общий баш-скрипт. Это отличная идея! Может, у вас есть пример скрипта, который вы используете в своих проектах? Было бы здорово сравнить варианты.
Про pyenv + uv + direnv — да, тут действительно получается "много слоёв". Моя цель была показать, как эти инструменты могут дополнять друг друга: pyenv для версий Python, uv для скорости и удобства управления зависимостями, а direnv для локальной настройки. Но я полностью согласен, что в продакшене это может быть перебор.
Кстати, про make — я добавил его для удобства, чтобы команды были под рукой, про scons, я кстати раньше не слышал, спасибо почитаю на досуге, что это за штука такая. А как вы автоматизируете свою "рутину", чтобы не плодить лишние инструменты?
Про несколько версий Python под Linux — в статье я хотел показать, как pyenv может помочь с этим, я им реально пользуюсь, так как в нём больше всего вариантов разных версий Python, под каждый рабочий проект подбираю нужную, по необходимости. Конечно, тут, достаточно было бы, просто использовать uv, он это позволяет, но на тот момент там не было 13-ой версии, либо я не обновил его, если она там была и не увидел.
И про HTTP/3 и nginx — отличное замечание! Granian пока действительно не поддерживает HTTP/3, и в продакшене это может быть ограничивающим фактором. В данном случае 3-ья версия протокола и не требовалась, более интересно посмотреть на производительность.
Если не затруднит, расскажите, пожалуйста, как вы видите идеальный сетап для такого проекта — может, я что-то упустил из этого и попробовав добавлю в следующую часть статьи 😊
Ещё раз благодарю за ваш комментарий!
А зачем нужен pyenv, если uv может любую версию питона поставить?
Добрый день, так же прошу прощения, что долго не мог ответить. Спасибо за ваш комментарий.
Вы совершенно правы, uv действительно умеет устанавливать разные версии Python, и это одна из его крутых фишек. Давайте я объясню, почему я всё-таки использовал pyenv.
Дело в том, что pyenv и uv решают немного разные задачи, хотя их функциональность и пересекается. pyenv я использовал как проверенный инструмент для управления версиями Python на уровне системы — он позволяет быстро переключаться между глобальными или локальными версиями интерпретатора и держать всё это под контролем через .python-version. Это особенно удобно, когда работаешь с несколькими проектами, где могут быть разные требования к версиям Python, и хочется, чтобы переключение происходило автоматически при входе в директорию (в связке с direnv, например).
В момент написания статьи я решил использовать uv больше как пакетный менеджер и "ускоритель" для работы с зависимостями, а установку версий Python доверил pyenv, чтобы показать их в связке. Возможно, это и правда избыточно. И на тот момент в uv не было 13-ой версии, либо я не обновил его, если она там была и не увидел.
LitestarCatsCV. Тренируемся на кошках. Пробуем litestar и другое новьё. Часть 1