Комментарии 16
venv не нужно устанавливать если python версии 3.3 и выше, т.к. в этих версиях модуль venv входит в стандартную библиотеку.
Не проще будет 1 раз поднять докер с питоном?
Вначале рассмотрим работу с 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.
Как настроить python в Linux под свой проект?