Pull to refresh

Comments 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.

Sign up to leave a comment.

Articles