Как настроить виртуальное окружение Python — кто сталкивался?

Введение

Виртуальное окружение в Python — это реально одна из тех вещей, без которых уже трудно представить серьёзную или даже просто более-менее аккуратную разработку. Поначалу, когда только начинаешь ковыряться, кажется, что это лишняя мутотень, но как только появляется второй проект и начинаешь ставить библиотеки в разных версиях, тут же всё становится очевидно. Плюс, если не использовать виртуальные окружения, можно легко "засрать" системный Python и потом долго рыться в проблемах зависимостей. А у многих библиотек — свои версии, чаще несовместимые с другими, так что без изоляции можно натворить бед.

В этой теме хочу поделиться тем, как я настраиваю виртуальные окружения, на что обращаю внимание и что с этим связано. Может, кто тоже расскажет свои лайфхаки или вопроcы будет — давайте обсудим.

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

Виртуальное окружение — это отдельная папка, где живёт изолированная копия интерпретатора Python и своя копия папки с установленными библиотеками. Всё, что ты ставишь через pip, попадает именно туда и не задевает глобальные системные библиотеки. Такой подход помогает:

- Избежать конфликтов между разными проектами, когда один требует старую библиотеку, а другой — новую;
- Сохранять систему в чистоте — не накатывать пакеты глобально, чтобы не сломать другие программы;
- Делать перенос проектов проще, потому что можно иметь рядом requirements.txt с точными версиями;
- Тестировать и разрабатывать в условиях, максимально похожих на продакшен (если там тоже используют виртуалки).

Пример из жизни — у меня есть два проекта: один на Django 2.2, который пока не обновили, и новый, где стоит Django 4.0. Если пытаться ставить всё глобально, были бы одни и те же версии библиотек — либо ломались бы старые проекты, либо новые. А так просто запускаю виртуальное окружение с нужной версией и работаю.

Как создать и активировать виртуальное окружение

На самом деле, способов много, но я обычно пользуюсь стандартным инструментом venv, который есть из коробки с питоном 3.3+.

1. В командной строке заходим в папку проекта (например, мой_проект/).
2. Выполняем команду:

python3 -m venv venv

Это создаст папку venv внутри проекта с окружением. Можно назвать её как угодно, но venv или env — стандарт.

3. Чтобы начать работать в этом окружении, нужно его активировать.

- Для Windows (cmd):

venv\Scripts\activate.bat

- Для PowerShell:

venv\Scripts\Activate.ps1

- Для Linux/macOS (bash/zsh):

source venv/bin/activate

После активации в командной строке должно появиться имя окружения, например (venv), и ты уже в изолированном пространстве. Все pip устанавливает сюда, а не в систему.

4. Когда нужно выйти из виртуального окружения:

deactivate

Работа с pip и requirements.txt

После активации виртуального окружения можно ставить библиотеки через pip:

pip install django==2.2

Чтобы сохранить список установленных библиотек с версиями, удобно сделать

pip freeze > requirements.txt

Так файл requirements.txt можно дать кому-нибудь или перенести на другую машину, а потом восстановить такое же окружение командой

pip install -r requirements.txt

Практический пример создания окружения и установки Flask

Допустим, хочешь сделать простой проект на Flask.

- Создаёшь папку:

mkdir flask_test
cd flask_test

- Создаёшь виртуальное окружение:

python3 -m venv venv

- Активируешь:

source venv/bin/activate (или соответствующая команда для вашей ОС)

- Устанавливаешь Flask:

pip install Flask

- Создаёшь файл app.py с простейшим кодом

from flask import Flask
app = Flask(__name__)

@app.route("/")
def hello():
return "Hello, Flask!"

- Запускаешь:

python app.py

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

Типичные ошибки и нюансы

1. Неактивированное окружение. Очень частая ошибка — забыть активировать виртуалку, пытаясь ставить пакеты. Тогда библиотеки ставятся глобально (часто без прав или в “другую” версию Python) — потом непонятки.

2. Путь к Python. Иногда в системе несколько версий питона. Если просто писать python, может запуститься версия 2.7 или другая. Стоит проверять python --version и лучше использовать python3 и python3 -m venv.

3. Использование старых версий pip или setuptools внутри окружения. При появлении ошибок с установкой пакетов стоит их обновить:

pip install --upgrade pip setuptools

4. Попытки создавать окружения внутри системных каталогов Python — бесполезно и вредно. Всегда лучше держать виртуалки прямо рядом с проектом.

5. Прописанные в requirements.txt диапазоны версий могут приводить к конфликтам. Лучше фиксировать конкретные версии, чтобы избежать сюрпризов.

6. Удаление папки с виртуальным окружением — часто бывает, что не понимают, что удаление venv — это потеря всех установленных пакетов и их придётся ставить заново.

7. Переключение между виртуальными окружениями путём их одновременного открытия в разных терминалах — следи, чтобы не путаться, в какой ты сейчас.

Дополнительные инструменты

Кроме стандартного venv, существуют и другие популярные утилиты:

- virtualenv — более старый и кроссплатформенный, иногда проще для некоторых случаев;
- pipenv — сочетает управление виртуалками и зависимостями с удобным Pipfile;
- poetry — современный менеджер зависимостей и паблишинга с удобным синтаксисом и lock-файлами;
- conda — отдельно стоит упомянуть, если работаешь с научным стеком, где важны бинарные зависимости.

Для простых проектов вполне хватает venv, а если разрастание набирает обороты — стоит попробовать pipenv или poetry.

Чек-лист перед началом работы с виртуальным окружением

- [ ] Проверить версию Python в терминале (python3 --version)
- [ ] Создать папку проекта и перейти в неё
- [ ] Запустить python3 -m venv venv (или другое имя)
- [ ] Активировать виртуальное окружение
- [ ] Обновить pip и setuptools внутри виртуалки
- [ ] Установить необходимые библиотеки через pip install
- [ ] Сохранить зависимости в requirements.txt (pip freeze > requirements.txt)
- [ ] Не забывать активировать окружение при каждом запуске работы с проектом
- [ ] Временно выходить из виртуалки через deactivate при необходимости
- [ ] При переносе проекта использовать pip install -r requirements.txt
- [ ] Держать виртуальное окружение в рамках проекта, не в системных папках

FAQ

Вопрос: Можно ли не использовать виртуальное окружение?
Ответ: Теоретически да, но практически это очень неудобно. Ломаются зависимости и приходится руками решать проблемы. Если только проект один и ничего не ставится — то можно и без него, но лучше всё же.

Вопрос: Как удалить виртуальное окружение?
Ответ: Просто удалить папку с ним (например, venv). Это безопасно, ничего кроме зависимостей проекта в ней нет. Просто потом надо будет заново ставить пакеты.

Вопрос: Можно ли использовать виртуальное окружение для Python 2?
Ответ: Да, но стандартный venv в Python 2 нет. Там пользуют virtualenv, который отдельно ставится и работает по похожему принципу.

Вопрос: Почему pip внутри виртуального окружения не работает?
Ответ: Обычно либо виртуалка не активирована, либо pip устарел. Попробуй обновить pip:

pip install --upgrade pip

Вопрос: Можно ли иметь несколько виртуальных окружений для одного проекта?
Ответ: Можно, но редко нужно. Обычно одно окружение на проект достаточно.

В общем, если кто-то ещё на старте, советую чуть поэкспериментировать с виртуальными окружениями. Это реально сильно облегчает жизнь с python-разработкой.

Давайте делитесь опытом, кто как привык работать с виртуалками, какие подводные камни встречали. Может, кто-то использует что-то более крутое, чем venv? Или наоборот, слишком замороченные варианты? Будет интересно почитать!