Используешь ли виртуальное окружение при разработке на Python

Что проверяют

Есть ли у вас гигиена зависимостей: отдельное окружение на проект, зафиксированные версии и воспроизводимая установка. Ответ «да, venv» слишком короткий. Следом спрашивают, чем вы пользуетесь кроме venv, как фиксируете версии и нужен ли venv в Docker.

Как отвечать

Виртуальное окружение это каталог со своим site-packages и ссылкой на интерпретатор. Пакеты ставятся туда, а не в систему, поэтому у двух проектов могут быть разные версии Django без конфликтов.

• venv: входит в стандартную библиотеку, python -m venv .venv. Активация не обязательна, можно вызывать .venv/bin/python напрямую;
• uv: быстрый менеджер от Astral, который во многих командах стал стандартом. uv venv, uv add, uv sync, лок-файл uv.lock, умеет ставить и сами версии Python;
• Poetry: зависимости и сборка пакета, poetry.lock;
• conda: для data science, когда нужны нативные библиотеки вроде CUDA и MKL.

Зависимости описывают в pyproject.toml, а точные версии фиксирует lock-файл. Если проект живёт на requirements.txt, его генерируют из списка прямых зависимостей через pip-compile или uv pip compile, а не через pip freeze из случайного окружения.

Полезно знать PEP 668: современные дистрибутивы Linux и Homebrew помечают системный Python как внешне управляемый, и pip install вне окружения падает с ошибкой externally-managed-environment. Так что venv сегодня почти обязателен.

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

Где спотыкаются

Думают, что venv меняет версию Python. Окружение использует тот интерпретатор, которым создано, а для переключения версий нужны pyenv или uv.

Коммитят .venv в репозиторий или переносят в другую папку. Пути внутри абсолютные, после переноса скрипты ломаются.

Лечат ошибку PEP 668 флагом --break-system-packages или sudo pip install и портят системные пакеты, от которых зависит сам дистрибутив.