virtualenv — инструмент для создания изолированных окружений Python. Каждое окружение содержит собственную копию интерпретатора Python и независимый набор установленных пакетов (site-packages). Это позволяет проектам использовать разные версии одной библиотеки без конфликтов: проект A требует Django 3.2, проект B — Django 5.0, и оба работают на одной машине.
Как использовать
# Создать окружение
python3 -m venv venv
# Активировать (Linux/macOS)
source venv/bin/activate
# Активировать (Windows)
venv\Scripts\activate
# Установить зависимости
pip install django==5.0 psycopg2
# Сохранить зависимости
pip freeze > requirements.txt
# Деактивировать
deactivateПосле активации which python показывает путь внутри venv/, а не системный. Переменная PATH временно переопределяется.
История
virtualenv создан Яном Биккингом (Ian Bicking) в 2007 году как решение проблемы «dependency hell» в Python. До virtualenv пакеты устанавливались глобально, что приводило к конфликтам версий. В Python 3.3 (2012) появился встроенный модуль venv — упрощённая версия virtualenv, интегрированная в стандартную библиотеку. virtualenv как отдельный проект продолжил развитие: он быстрее, поддерживает Python 2/3 и дополнительные опции создания окружений. С 2020-х годов Conda и Poetry стали популярными альтернативами для data science и управления зависимостями.
virtualenv vs venv vs Conda
| Инструмент | Встроен | Python 2 | Non-Python пакеты | Применение |
|---|---|---|---|---|
| virtualenv | Нет (pip install) | Да | Нет | Веб-разработка |
| venv (stdlib) | Python 3.3+ | Нет | Нет | Простые проекты |
| Conda | Нет (Miniconda) | Да | Да (C, R) | Data science, ML |
virtualenvwrapper и Poetry
virtualenvwrapper — обёртка для удобного управления окружениями: mkvirtualenv project, workon project, deactivate. Poetry — современный менеджер зависимостей и упаковщик, который управляет виртуальным окружением автоматически через pyproject.toml; рекомендован для новых проектов начиная с 2021 года. pipenv — альтернатива, создаёт Pipfile и Pipfile.lock.
На что обращать внимание в хостинге
На VPS с Python-приложениями виртуальное окружение — обязательная практика. При деплое через CI/CD: окружение создаётся заново из requirements.txt или pyproject.toml. В Docker-контейнерах виртуальное окружение часто избыточно — контейнер сам является изолированным окружением, но его использование допустимо в многоступенчатых сборках для точного контроля зависимостей. На PaaS-платформах (Heroku, Railway) requirements.txt читается автоматически без необходимости управлять venv вручную.
virtualenv vs venv vs conda vs poetry
| Инструмент | Когда использовать | Особенности |
|---|---|---|
python -m venv | Большинство проектов | Встроен в Python 3.3+ |
| virtualenv | Python 2, ускорение создания | Pip-пакет, cache пакетов |
| Conda | Data science, ML | C/FORTRAN-библиотеки, non-Python пакеты |
| poetry | Библиотеки, публикация PyPI | pyproject.toml, lock-файл |
История virtualenv
virtualenv создан Яном Биккингом (Ian Bicking) в 2007 году. В Python 3.3 (2012) появился стандартный venv. На VPS с несколькими Python-приложениями каждое получает собственное окружение. Gunicorn запускается с интерпретатором из venv: /opt/app/venv/bin/gunicorn app:application. В systemd-юните ExecStart указывает на бинарник внутри venv. В Docker виртуальное окружение избыточно.