> For the complete documentation index, see [llms.txt](https://rksi.gitbook.io/django/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://rksi.gitbook.io/django/sozdanie-virtualnoi-sredy-okruzheniya.md). # Создание виртуальной среды (окружения) Для работы с Django необходимо сначала создать виртуальную среду для работы. Виртуальная среда представляет собой подраздел системы, в котором вы можете устанавливать пакеты в изоляции от всех остальных пакетов Python. Отделение библиотек одного проекта от других проектов принесет пользу при развертывании(deploy) проекта на сервере. ## Виртуальные окружения Система управления пакетами Pip устанавливает пакеты в одно из двух окружений — в **общесистемное** или **пользовательское**. Интерпретатор Python при импорте модуля или пакета ищет его сначала в **пользовательском** окружении, затем — в **общесистемном**. Такая последовательность позволяет пользователю иметь нужные именно ему версии библиотек. Но даже двух окружений недостаточно, когда программист начинает работать с несколькими проектами, ведь разные проекты могут иметь разные наборы **зависимостей**. Еще более тяжелый случай: разные проекты могут зависеть от общей библиотеки, но требовать разные ее версии — тогда происходит конфликт версий. Очевидно, что разработчику на Python нужен какой-то механизм, позволяющий содержать разные проекты в изолированных песочницах. Такой механизм существует. Он называется **виртуальные окружения**. ### Устройство виртуальных окружений Каждое виртуальное окружение представляет собой директорию. Ее содержимое структурно напоминает **общесистемное** окружение — поддиректории соответственно названы и наполнены. Давайте рассмотрим пример: ```bash tree env ``` ```bash env ├── bin │   ├── activate │ … │   ├── pip3 │ ├── pip3.11 │ ├── pip3.9 │   … │   ├── python3 -> python │ └── python3.9 -> python ├── lib │   └── python3.9 │   └── site-packages │   ├── pip │   │   ├── … │ … │   └── setuptools-68.1.2.dist-info │      ├── … … ``` В директории виртуального окружения находится директория `bin/`, внутри которой расположены: * Копия интерпретатора под именем **`python3`** (символическая ссылка на оригинал) * Копия исполняемого файла **`pip`** В соседней директории по пути **`lib/python3.9/site-packages`** есть библиотеки, уже установленные в окружение. Как правило, только что созданное окружение имеет: * Установленный пакет pip (исполняемый файл **`bin/pip`** — его точка входа) * Пакет Setuptools Эти два пакета составляют необходимый минимум для разработки проекта на Python. При работе в окружении нужно запускать не системные Python и pip, а исполняемые файлы из директории **`bin`**. Когда интерпретатор Python находится в окружении, он знает, где находятся все доступные пакеты. Интерпретатор находит их по относительному пути **`../lib/python3.9`**. В таком случае копия **`pip`** из директории **`bin/`** устанавливает пакеты в это же окружение, не затрагивая систему. Получается та самая изоляция. ### Создание виртуального окружения Вручную создавать всю описанную иерархию директорий и файлов не нужно — для этого есть специальный модуль **`venv`**. В **macOS** и **Windows** этот модуль входит в поставку Python. На **Ubuntu** его нужно установить отдельно командой: 
sudo apt install python3-venv
```bash python3 -m venv --help ```

Примерный вывод консоли

Обычно окружение создается командой. ```bash python3 -m venv `имя окружения` ``` Давайте попробуем создать виртуальное окружение с именем **`my_venv`** и установить туда пакет **`cowsay`**: Пакет устанавливается вместе с точкой входа, которую можно вызвать командой **`my_venv/bin/cowsay`**. Также сам пакет становится доступен интерпретатору, но только тому, что был **запущен из окружения**.

Установка и вызов пакета без активации

В таком виде виртуальное окружение уже можно использовать полноценно. Но постоянно вводить команды с префиксом **`my_venv/bin/`** не очень удобно. Есть способ упростить вызов команд, доступных в окружении — это **активация**. ### Активация окружения При создании окружения в поддиректорию **`bin`** помещается сценарий оболочки, который на macOS и Ubuntu называется **`activate`**, а на Windows — **`activate.bat`**. Чтобы выполнить этот сценарий, нужно вызвать команду: * на macOS и Linux: ```bash source my_venv/bin/activate ``` * на Windows: ```sh C:\> my_venv\Scripts\activate.bat ``` {% hint style="warning" %} В команде выше обратите внимание, что в Windows поддиректория с исполняемыми файлами называется не **`bin`**, а **`Scripts`**. {% endhint %} На Mac и Linux активация выглядит следующим образом:

Активация окружения

После активации отпала необходимость указывать путь до вызываемого исполняемого файла. Теперь **cowsay** и **python** вызываются без префикса, но это все те же команды из окружения. Еще изменилось приглашение оболочки: в нем стало отображаться имя окружения. Это работает на **macOS** и **Linux** и всегда напоминает, что мы находимся в виртуальном окружении. Деактивация окружения делается командой **`deactivate`**, которая становится доступна после активации. В последней строке мы видим ошибку ``` command not found: cowsay ``` Командой **`deactivate`** мы вышли из окружения **`my_venv`** и попытались вызвать пакет **`cowsay`** Активация и деактивация окружения влияют только на текущую сессию — то есть заметны только в этом конкретном терминале. Это удобно, потому что так можно иметь несколько окружений и активировать их одновременно в разных окнах терминала. ### Выводы Виртуальные окружения — мощный и удобный инструмент изоляции программ друг от друга и от системы. Изоляция позволяет использовать даже разные версии Python в разных окружениях — при работе над проектами разного "возраста" такое часто бывает жизненно необходимо. [^1]: