Какую виртуальную среду для Python предпочитаешь

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

Умеете ли вы изолировать зависимости проекта и воспроизводить окружение на другой машине, а не только знаете команду python -m venv. Следом обычно спрашивают, как вы фиксируете версии пакетов и чем пользуется ваша текущая команда.

Как отвечать

Назовите свой выбор и объясните его задачей, а не вкусом. Полезно показать, что вы различаете слои:

• venv: встроен в стандартную библиотеку, создаёт изолированный каталог с интерпретатором и site-packages. Версиями Python не управляет, лок-файла не даёт;
• pyenv: ставит и переключает сами версии Python. Это не замена venv, а слой под ним;
• Poetry: зависимости в pyproject.toml, точные версии в poetry.lock, окружение создаёт сам. Удобен для библиотек и сервисов;
• uv: быстрый менеджер на Rust, совмещает venv, pip, pip-tools и установку интерпретаторов, пишет uv.lock. В новых проектах его выбирают всё чаще;
• conda: нужна, когда кроме Python-пакетов требуются бинарные зависимости, например CUDA или научные библиотеки.

Хороший ответ звучит так: «Держу .venv в корне проекта и управляю им через uv или Poetry, потому что нужен лок-файл и одинаковые версии у всей команды и в CI. Если проект живёт на requirements.txt, фиксирую версии через pip-compile». Добавьте, что активировать окружение не обязательно: можно вызывать .venv/bin/python напрямую, так делают в скриптах и Dockerfile. И упомяните PEP 668: в свежих Debian и Ubuntu системный pip install без окружения блокируется ошибкой externally-managed-environment.

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

Путают pyenv и venv: первый управляет версиями интерпретатора, второй изолирует пакеты, и в проекте обычно нужны оба.

Кладут каталог окружения в git. Он привязан к пути и платформе, в репозитории должны лежать pyproject.toml и лок-файл, а .venv уходит в .gitignore.

Считают pip freeze > requirements.txt полноценной фиксацией. В файл попадают транзитивные пакеты вперемешку с прямыми, и через полгода уже непонятно, что проект действительно использует.