Как стать автором
Обновить

Комментарии 16

venv не нужно устанавливать если python версии 3.3 и выше, т.к. в этих версиях модуль venv входит в стандартную библиотеку.

Согласен, но в статье это позволило установить/обновить ещё ряд необходимых пакетов. Посмотрите на скрин в статье.

Не проще будет 1 раз поднять докер с питоном?

Когда в руках молоток - всё вокруг похоже на гвозди ;) Можно и целую виртуальную машину развернуть. Но иногда venv достаточно.

В точку!

А в проде будет кубер с образом на базе arch linux

Вначале рассмотрим работу с python библиотеками в Linux.

То что вы описываете имеет весьма опосредованное отношение к Linux - вы пишете про Debian-based дистрибутивы. Важно понимать разницу. В Arch или CentOS packet manager отличается. Но это тоже Linux.
Ну и про venv lib вам уже написали выше.
Поправьте пожалуйста.

Спасибо за комментарий! В статье ориентировался на самые распространённые дистрибутивы. Если описывать работу с python во всех дистрибутивах, то получится целая техническая документация 

Статья ориентирована на Debian-based дистрибутивы (а если быть точнее на дистрибутивы с APT). Комментатор сделал правильное замечание, что не описана работа в других дистрибутивах (CentOS тоже, так-то, распространен, как серверная OS)

Статья в целом не соответствует заголовку, что печалит – "работа" с linux заканчивается на установке venv, который спокойно можно поставить через pip. Хотелось бы всё таки увидеть тонкие вещи точно специфичные для linux и связанные с настройкой

И еще стоит описать pyenv - когда вам нужно иметь несколько версий Python для разных проектов можно установить разные версии в разных venv.

Я обычно использую такую последовательность в CI/CD:

            #  pyenv setup
            export PYENV_ROOT="$HOME/.pyenv"
            command -v pyenv >/dev/null || export PATH="$PYENV_ROOT/bin:$PATH"
            eval "$(pyenv init -)"
            #  Python 3.8.0 virtual environment setup 
            pyenv local 3.8.0
            python3 -m venv ./venv
            source venv/bin/activate
            pip install --upgrade pip
            #  Ansible install            
            pip install ansible
            ansible-galaxy collection install f5networks.f5_modules
            E.T.C.

Вне CI/CD пропускаю секцию pyenv setup - обычно все уже настроено в ~/.bashrc

Ну и модули, соответственно, устанавливаю не в систему, а в venv при помощи pip install. Это позволяет даже при одинаковой версии Python иметь разные версии библиотек в разных проектах.

Спасибо, важное дополнение!

 

Виртуальное окружение со всеми необходимыми настройками можно «передавать» вместе с вашим приложением. Так другому разработчику будет проще работать с вашим проектом.

Нифига не проще, если у другого разработчика стоит задача не просто запустить проект, но и интегрировать его в большую систему.

А в чём проблема? Стандартный способ - передавать все зависимости в requirements.txt.

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

Конечно, для больших систем никто не будет использовать pyvenv, pyenv или poetry. Для этого целесообразнее применять docker.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории