Виртуальное окружение venv: как изолировать Python-проект

Виртуальное окружение отделяет интерпретатор и устанавливаемые пакеты одного проекта от пакетов другого. Благодаря этому два приложения на одном компьютере могут использовать…

Виртуальное окружение отделяет интерпретатор и устанавливаемые пакеты одного проекта от пакетов другого. Благодаря этому два приложения на одном компьютере могут использовать разные версии библиотеки, а экспериментальная установка не меняет рабочее окружение соседнего проекта. Модуль venv входит в стандартную библиотеку Python и создаёт такую изоляцию без отдельного менеджера окружений.

Что именно изолирует venv

В каталоге окружения находятся исполняемый файл Python, служебная конфигурация и собственный каталог site-packages. Обычная установка через pip попадает туда, если команда запущена этим интерпретатором. По умолчанию пакеты глобального Python не добавляются в окружение; специальный режим --system-site-packages меняет это правило и потому не подходит как бездумная настройка.

venv не является контейнером или механизмом безопасности. Он не изолирует процессы, сеть, переменные окружения и системные библиотеки. Его задача уже: дать проекту отдельный Python-контекст и предсказуемое место для зависимостей.

Создание и активация

Окружение обычно создают в корне проекта под именем .venv. Команда python3 -m venv .venv явно запускает модуль тем Python, который выбран для проекта. В Linux и macOS активация выполняется скриптом source .venv/bin/activate; в Windows PowerShell используется .venv\Scripts\Activate.ps1.

mkdir weather-console
cd weather-console
python3 -m venv .venv
source .venv/bin/activate
python -c "import sys; print(sys.executable)"
python -c "import sys; print(sys.prefix != sys.base_prefix)"

Ожидаемый результат — путь, заканчивающийся на weather-console/.venv/bin/python, и строка True. Абсолютная часть пути зависит от компьютера. Команда deactivate возвращает shell к прежнему поиску Python, но не удаляет файлы окружения.

Активация не обязательна

Скрипт активации лишь ставит каталог окружения в начало PATH и меняет несколько переменных текущего shell. В CI, cron и IDE надёжнее указывать интерпретатор прямо: .venv/bin/python -m pip install -r requirements.txt или .venv/bin/python app.py. Такой вызов не зависит от того, какой shell был открыт раньше.

Каталог .venv не переносят между компьютерами и не коммитят: внутри есть абсолютные пути и платформенно-зависимые файлы. В репозиторий помещают исходники и описание зависимостей, а окружение пересоздают. Поэтому .venv/ следует добавить в .gitignore.

Почему пакет установлен, но не импортируется

Характерный симптом — пакет успешно «установлен», но программа отвечает ModuleNotFoundError. Часто pip и программа относятся к разным интерпретаторам: установка произошла до активации либо команда pip найдена в другом PATH. Сравните python -c "import sys; print(sys.executable)" и python -m pip --version: оба пути должны указывать внутрь одной .venv. Затем проверьте пакет через python -m pip show имя_пакета. Если само создание окружения сообщает об отсутствующем ensurepip, это свойство конкретной установки Python; проверьте документацию пакета Python для своей ОС, а не копируйте чужой путь к окружению.

Проверяем изоляцию двух проектов

Создайте каталоги project-a и project-b, в каждом сделайте собственную .venv. В первом окружении установите небольшой тестовый пакет, а во втором не устанавливайте. С помощью sys.executable, sys.prefix и python -m pip show докажите, где пакет доступен. Закройте терминал, не выполняйте активацию и повторите проверку прямым вызовом .venv/bin/python. Самостоятельная проверка пройдена, если результаты не зависят от глобальной команды pip.

Контрольный список рабочего окружения

• Окружение связано с конкретным интерпретатором и хранит собственные устанавливаемые пакеты.
• python -m pip уменьшает риск запустить pip не от того Python.
• Активация удобна человеку, но прямой путь к интерпретатору надёжнее для автоматизации.
• .venv пересоздают из описания зависимостей и не считают переносимым артефактом.

Вопросы об активации и переносимости venv

Нужно ли новое окружение для каждого проекта?

Да, это полезное правило по умолчанию. Даже проекты с одинаковыми зависимостями развиваются независимо, и отдельные окружения не дают случайному обновлению одного проекта повлиять на другой.

Почему приглашение shell показывает (.venv), но запускается не тот Python?

Текст приглашения — лишь подсказка. Alias, функция shell или изменение PATH после активации могут повлиять на поиск. Источником истины остаются sys.executable и python -m pip --version.

Можно ли просто скопировать .venv на сервер?

На это не следует рассчитывать. Окружение содержит пути и файлы, зависящие от ОС и сборки Python. На сервере безопаснее создать его заново и установить зафиксированные зависимости.