Python venv: виртуальное окружение на Linux — полный гайд

Виртуальное окружение Python создаётся командой python3 -m venv venv и активируется через source venv/bin/activate. После активации pip install устанавливает пакеты только в это окружение, не затрагивая системный Python и другие проекты. venv встроен в Python 3.3+ — устанавливать ничего дополнительно не нужно.

Зачем нужно виртуальное окружение

Представьте: проект А требует Django 3.2, проект Б — Django 4.2. Если устанавливать пакеты глобально через pip install, второй проект перезапишет зависимости первого, и один из них сломается.

Виртуальное окружение изолирует зависимости каждого проекта в отдельную папку. Проект А видит только свои пакеты, проект Б — свои. Конфликтов нет.

На сервере это ещё важнее: глобальная установка пакетов через pip может сломать системные утилиты которые зависят от Python. Некоторые дистрибутивы даже блокируют глобальную установку через pip — именно поэтому pip install без venv выдаёт ошибку externally-managed-environment на Ubuntu 23.04 и новее.

Установка python3-venv

На большинстве систем venv доступен сразу. Если получаете ошибку No module named venv:

sudo apt install python3-venv python3-pip -y

Создание виртуального окружения

Перейдите в папку проекта и создайте окружение:

cd ~/myproject
python3 -m venv venv

Папка venv создастся внутри проекта. Внутри неё — изолированная копия Python интерпретатора и пустой site-packages для зависимостей.

Альтернативное название .venv (с точкой в начале) — скрытая директория, современное соглашение в Python-сообществе:

python3 -m venv .venv

Выбор между venv и .venv — вопрос предпочтений. Главное: оба варианта нужно добавить в .gitignore.

Активация и деактивация

Активируйте окружение:

source venv/bin/activate

После активации в начале приглашения командной строки появится имя окружения:

(venv) user@server:~/myproject$

Это визуальный сигнал что окружение активно. Теперь python и pip указывают на версии внутри venv, а не системные.

Проверить:

which python
# → /home/user/myproject/venv/bin/python

Деактивировать когда работа закончена:

deactivate

Работа с пакетами внутри окружения

Установить пакет:

pip install requests flask

Обновить pip до актуальной версии (pip внутри нового venv часто устаревший):

pip install --upgrade pip

Посмотреть установленные пакеты:

pip list

requirements.txt: сохранение и восстановление зависимостей

requirements.txt — стандартный способ зафиксировать точные версии всех зависимостей проекта.

Важный нюанс: для создания requirements.txt нужна команда pip freeze, а не pip list:

pip freeze > requirements.txt

Разница принципиальная. pip list выводит читаемый список без форматирования, непригодный для автоматической установки. pip freeze выводит строки вида requests==2.31.0 — именно такой формат понимает pip install -r.

Посмотреть содержимое файла:

cat requirements.txt

Установить зависимости из файла — например, при развёртывании проекта на новом сервере или после клонирования репозитория:

pip install -r requirements.txt

Никогда не коммитьте venv в git

Папка venv весит 50-300 МБ в зависимости от установленных пакетов. Она содержит бинарники скомпилированные под конкретную ОС — они не работают на другой системе. И она полностью воссоздаётся из requirements.txt за одну команду.

Добавьте в .gitignore:

echo "venv/" >> .gitignore
echo ".venv/" >> .gitignore

Или создайте .gitignore с содержимым:

venv/
.venv/
__pycache__/
*.pyc
*.pyo
.env

Как проверить что окружение активно

Три способа убедиться:

echo $VIRTUAL_ENV

Выведет путь к venv если активен, пустую строку если нет.

which python

Должен указывать на venv/bin/python, не на /usr/bin/python3.

python -c "import sys; print(sys.prefix)"

Выведет путь к директории venv.

Venv в cron-задачах

Это критичный момент для работы на VPS. Когда cron запускает скрипт, виртуальное окружение не активировано — команда python script.py будет использовать системный Python без нужных зависимостей и упадёт с ModuleNotFoundError.

Неправильно:

0 3 * * * cd /home/user/myproject && python script.py

Правильно — использовать полный путь к Python внутри venv:

0 3 * * * /home/user/myproject/venv/bin/python /home/user/myproject/script.py

Не пытайтесь активировать venv через source в cron — cron запускает задачи в неинтерактивной оболочке где source работает непредсказуемо.

Venv в systemd-сервисе

Аналогичная история при запуске Python-приложения как systemd-сервиса:

[Unit]
Description=My Python App
After=network.target

[Service]
Type=simple
User=ubuntu
WorkingDirectory=/home/ubuntu/myproject
ExecStart=/home/ubuntu/myproject/venv/bin/python app.py
Restart=on-failure

[Install]
WantedBy=multi-user.target

Ключевая строка: ExecStart указывает на Python внутри venv. Systemd не наследует переменные окружения пользователя, активация через source здесь тоже не работает.

Пересоздание окружения

Если нужно начать с чистого листа:

deactivate
rm -rf venv
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt

Для обновления версии Python в существующем venv:

python3 -m venv venv --upgrade

Сравнение инструментов для изоляции Python

Инструмент	Встроен	Когда использовать
venv	Да (Python 3.3+)	Большинство проектов, стандартный выбор
virtualenv	Нет	Нужна поддержка Python 2 или более быстрое создание
conda	Нет	Data science, нужны не-Python зависимости (numpy с CUDA)
pipenv	Нет	Хотите Pipfile вместо requirements.txt
poetry	Нет	Разработка пакетов, нужен lock-файл и публикация на PyPI

Для типичных веб-приложений и скриптов на VPS — venv оптимальный выбор: встроен, прост, понятен.

Быстрая шпаргалка

# Создать
python3 -m venv venv

# Активировать
source venv/bin/activate

# Установить зависимости
pip install -r requirements.txt

# Добавить новую зависимость
pip install название-пакета

# Сохранить зависимости
pip freeze > requirements.txt

# Деактивировать
deactivate

# В cron/systemd — полный путь
/path/to/project/venv/bin/python script.py

Часто задаваемые вопросы

Нужно ли устанавливать venv отдельно?

Нет, venv встроен в Python начиная с версии 3.3. На Ubuntu может потребоваться sudo apt install python3-venv — это пакет который делает модуль доступным, но сам venv является частью стандартной библиотеки Python.

В чём разница между pip freeze и pip list?

pip list выводит читаемую таблицу пакетов — удобно для просмотра. pip freeze выводит строки формата пакет==версия — именно этот формат понимает pip install -r. Для создания requirements.txt всегда используйте pip freeze.

Почему Python-скрипт не находит пакеты в cron?

Потому что cron не активирует виртуальное окружение автоматически. Используйте полный путь к Python внутри venv: /path/to/project/venv/bin/python script.py вместо просто python script.py.

Можно ли использовать одно venv для нескольких проектов?

Технически да, но это плохая практика. Разные проекты могут требовать разные версии одних и тех же пакетов, и общее окружение в какой-то момент сломается. Создавайте отдельный venv для каждого проекта.

Что делать с ошибкой externally-managed-environment?

Эта ошибка появляется в Ubuntu 23.04 и новее при попытке pip install без активированного venv. Система защищает от загрязнения системного Python. Решение: создайте venv и устанавливайте пакеты внутри него — именно так и должно быть.

Python-приложения на VPS удобнее запускать с изолированными зависимостями через venv — это исключает конфликты пакетов и упрощает деплой.
На UFO.Hosting серверы с Ubuntu 22.04 и 24.04 разворачиваются за минуты: Python 3 и pip доступны сразу после подключения.