Что такое виртуальная среда python
Установка и использование virtualenv в Python
virtualenv — это инструмент для создания изолированной среды Python. У такой среды есть отдельна установка python, при ее использовании загруженные библиотеки недоступны другим. Можно сделать так, чтобы у этой среды не было доступа к глобальным библиотекам.
Virtualenv — простой и рекомендованный способ настройки среды Python.
Отличия virtualenv и venv
Venv — это пакет, который идет по умолчанию с Python 3.3+. В версии Python 2 его нет.
Virtualenv — более продвинутая библиотека. По ссылке можно ознакомиться с основными отличиями.
Виртуальную среду можно создать и с помощью venv, но все-таки рекомендуется установить и использовать virtualenv для полноценной работы.
Установка virtualenv с помощью pip
Для установки virtualenv с Python нужно использовать pip. Желательно предварительно обновить этот инструмент.
После обновления можно установить и virtualenv:
Создание виртуальной среды
1. Перейдите в директорию, в которой вы хотите создать виртуальную среду(например папка проекта).
Назвать среду можно как угодно
После выполнения команды вы увидите логи:
Эта команда создает локальную копию среды. Работая с ней, важно не забывать об активации, чтобы использовались нужные версии конкретных инструментов и пакетов.
3. Для активации новой виртуальной среды используйте команду:
После этого название текущей среды отобразится слева от символа ввода: (venv_name) username@desctop:
Теперь при установке любого пакета с помощью pip он будет размещаться в папках этой среды, изолированно от глобальной установки.
Деактивации virtualenv
Введите ее и приставка venv_name пропадет. Вы вернетесь к использованию глобально версии python.
Удаление виртуальной среды
Для удаления виртуальной среды достаточно просто удалить папку проекта. Для этого используется следующая команда:
Решение популярных ошибок
Ошибки при создании virtualenv. При попытке создать virtualenv с Python 3.7 могут возникнуть следующие ошибки.
Использование полного пути к виртуальной среде. Может быть такое, что при использовании команды virtualenv будет использована не та версия. Для решения проблемы нужно лишь задать полные пути как к virtualenv, так и к Python в системе.
А получить их можно с помощью этой команды:
Виртуальная среда Python – Основы
В данной статье мы рассмотрим, как использовать виртуальную среду для создания и управлять ими отдельно в ваших проектах Python, используя разные версии Python для выполнения, а также рассмотрим, как хранятся и разрешаются зависимости Python.
Зачем нужна виртуальная среда?
Python, как и большая часть других современных языков программирования, имеет собственный, уникальный способ загрузки, хранения и разрешения пакетов (или модулей). Это имеет свои преимущества, однако были принятые некоторые интересные решения, на счет хранения и разрешения пакетов, которые привели к определенным проблемам, а именно: как и где эти пакеты хранятся?
Содержание
Существует несколько разных расположений, в которых хранятся пакеты, которые можно установить в вашей системе. Например, большая часть системных пакетов хранятся в дочернем каталоге пути, который, в свою очередь, хранится в sys.prefix.
Есть вопросы по Python?
На нашем форуме вы можете задать любой вопрос и получить ответ от всего нашего сообщества!
Telegram Чат & Канал
Вступите в наш дружный чат по Python и начните общение с единомышленниками! Станьте частью большого сообщества!
Паблик VK
Одно из самых больших сообществ по Python в социальной сети ВК. Видео уроки и книги для вас!
На Mac OS X, вы можете легко найти, где именно sys.prefix указывает на использование оболочки Python:
К нашей статье в большей мере относятся сторонние пакеты, установленные при помощи easy_install или pip, обычно располагаются в одном из каталогов, на которую указывает site.getsitepackages:
Зачем нам все эти детали?
Очень важно иметь представление об этом, так как по умолчанию, каждый объект вашей системы будет использовать одинаковые каталоги для хранения и разрешения пакетов (сторонних библиотек. На первый взгляд это не выглядит чем-то значительным. Это так, но только в отношении системных пакетов, являющихся частью стандартной библиотеки Python – но сторонние пакеты – это другое дело.
Представим следующий сценарий, где у вас есть два проекта: проект А и проект Б, которые оба имеют зависимость от одной и той же библиотеки – проект В. Проблема становится явной, когда мы начинаем запрашивать разные версии проекта В. Может быть так, что проект А запрашивает версию 1.0.0, в то время как проект Б запрашивает более новую версию 2.0.0, к примеру.
Это большая проблема Python, поскольку он не может различать версии в каталоге «site-packages». Так что обе версии 1.0.0 и 2.0.0 будут находиться с тем же именем в одном каталоге:
И так как проекты хранятся в соответствии с их названиями, то нет различий между версиями. Таким образом, проекты А и Б должны будут использовать одну и ту же версию, что во многих случаях неприемлемо.
Тут-то и вступает в игру виртуальная среда (вместе с инструментами virtualenv/ven)
Что такое виртуальная среда?
В корне своем, главная задача виртуальной среды Python – создание изолированной среды для проектов Python.
Каждый проект может иметь свои собственные зависимости, вне зависимости от того, какие зависимости у другого проекта.
И так, в нашем небольшом примере вверху, нам просто нужно создать раздельную виртуальную среду для проектов А и Б. Каждая среда, в свою очередь, сможет зависеть от любой версии проекта В, независимо друг от друга.
Это хорошо тем, что у нас нет ограничений на то, в скольких экземплярах будет наша виртуальная среда, так как они являются обычными каталогами, в которых содержится несколько скриптов. Плюс, их очень легко создать при помощи инструментов командной строки virtualenv или pyenv.
Использование виртуальной среды
Перед тем, как начать: если вы не пользуетесь Python 3, вам нужно будет установить инструмент virtualenv при помощи pip:
Если вы используете Python 3, у вас уже должен быть модуль venv, установленный в стандартной библиотеке.
Предположим, что вы пользуетесь последней версией инструмента venv, так как между ним и virtualenv существует несколько различий в отношении команд. По большому счету, это два весьма разных инструмента.
Начнем с создания нового каталога, с которым мы будем работать:
Создание новой виртуальной среды внутри каталога:
По умолчанию, это не включает в себя ни один из существующих сторонних пакетов.
Подход venv в Python 3 обладает преимуществом, которое вынуждает вас использовать определенную версию интерпретатора Python 3, который будет использован для создания виртуальной среды. Таким образом, вы избегаете недоразумений при выяснении, какая инсталляция Python базируется в новой виртуальной среде.
В примере выше, эта команда создает каталог под названием «env», структура каталога которого схожа со следующей:
Что находится в этих папках?
Далее, у нас есть копии или символические ссылки нескольких различных инструментов Python. Эти файлы используются для обеспечения того, чтобы команды и код Python выполнялись в контексте нынешней среды, таким образом, достигается изоляция от глобальной среды. Мы рассмотрим это детальнее в следующем разделе.
Более интересные сейчас – скрипты activate в папке bin. Эти скрипты используются для настройки вашей оболочки для использования исполняемого файла среды Python и его сайтовых пакетов по умолчанию.
Чтобы использовать эти пакеты (или ресурсы) среды в изоляции, вам нужно «активировать» их. Чтобы сделать это, просто запустите:
Обратите внимание на то, что ваше приглашение командной строки теперь носит префикс вашей среды (в нашем случае – env). Это индикатор того, что env в данный момент активен, что в свою очередь говорит о том, что выполнимые файлы Python используют пакеты и настройки только этой среды.
Чтобы показать изолированный пакет в действии, мы можем использовать модуль bcrypt в качестве примера. Скажем, что модуль bcrypt установлен где-нибудь в системе, но не в нашей виртуальной среде.
Теперь ваш сеанс оболочки вернулся в норму, а команда python ссылается на общую установку Python. Помните: это можно делать когда угодно, после закрытия определенной виртуальной среды.
Теперь установим bcrypt и используем его для хеширования пароля:
Что произойдет, если мы попробуем ту же команду, когда виртуальная среда активна?
В одном примере, у нас есть доступный нам bcrypt, а в другом его нет. Это тот тип разделения, который мы ищем для виртуальной среды, и мы к нему пришли.
Как работает виртуальная среда?
Что именно имеется ввиду под «активировать» среду? Понимание того, что именно происходит под капотом, может быть очень важно для разработчика, особенно когда вам нужно понять выполнение виртуальной среды, разрешение зависимостей, и так далее.
Чтобы объяснить, как это работает, для начала проверим расположения разных исполняемых файлов python. С «деактивированной» средой запускаем:
Теперь активируем и снова запустим команду:
Активировав среду, мы теперь получаем другой путь к исполнимому файлу python, так как в активной среде, переменная среды $PATH несколько отличается.
Обратите внимание на разницу между первым путем в $PATH до и после активации:
В последнем примере, каталог bin нашей виртуальной среды теперь находится в начале пути. Это значит, что это первый каталог в поиске, когда мы запускаем исполняемый файл в командной строке. Таким образом, оболочка использует экземпляр нашей виртуальной среды в Python, а не в системной версии.
Другие пакеты, связывающие Python, такие как Anaconda, также могут выполнять манипуляции с вашим путем, если вы активируете их. Просто имейте это ввиду на случай, если вы столкнетесь с проблемами, связанными с другими виртуальными средами. Проблема может возникнуть при активации нескольких сред одновременно.
Это наталкивает на вопросы:
Это можно объяснить тем, как Python запускается и где он расположен в системе. Нет разницы между двумя исполняемыми файлами Python. Суть заключается в расположении каталога
Когда Python запускается, он ищет путь своего двоичного файла (в виртуальной среде он является копией или символической ссылке системного бинарного файла Python). Далее, он устанавливает расположение sys.prefix и sys.exec_prefix согласно с этим расположением, опуская часть bin в пути.
Путь, находящийся в sys.prefix далее используется для поиска каталога site-packages, путем поиска по связанного с ним пути lib/pythonX.X/site-packages/, где Х.Х – это версия используемого вами Python.
В нашем примере, бинарный файл расположен в /Users/michaelherman/python-virtual-environments/env/bin, это значит, что sys.prefix может быть /Users/michaelherman/python-virtual-environments/env, следовательно, используемый каталог site-packages может быть /Users/michaelherman/python-virtual-environments/env/lib/pythonX.X/site-packages. Наконец, этот путь наложен в массиве sys.path, который содержит все расположения, которые пакет может использовать.
Управление виртуальной средой при помощи virtualenvwrapper
Несмотря на то, что виртуальная среда определенно решает ряд проблем с управлением пакетами, она не идеальна. После создания нескольких виртуальных сред, вы обнаружите, что они создают некоторые проблемы сами по себе, большая часть которых вращается вокруг управления самими виртуальными средами. Чтобы помочь с этим, был создан инструмент virtualenvwrapper, который представляет собой набор оберточных скриптов вокруг основного инструмента virtualenv.
Самые полезные функции virtualenvwrapper:
Некоторые функции могут показаться узкими, или незначительными, вы быстро поймете, что они – это отличные инструменты для вашего рабочего ритма.
Перед началом, вы можете скачать обёртку при помощи pip:
Понятие о виртуальных средах в Python
Введение в виртуальные среды Python с использованием VR
Нет, вам не нужны очки виртуальной реальности (VR) для чтения этой статьи. Будет достаточно внимательности и интереса к теме.
Если вы новичок в мире науки о данных и Python, то виртуальные среды могут показаться чем-то очень сложным. Но на деле все совсем не так. Виртуальные среды просты для освоения и еще проще в работе! Если вам уже доводилось иметь дело с виртуальной реальностью (например, вы играли в игры с виртуальной реальностью или пользовались VR-очками), то у вас будет явное преимущество. В данной статье будет подробно рассказано обо всем, начиная с понятия о виртуальной среде и заканчивая ее установкой и использованием!
Что такое среда?
В человеческом понимании среда ассоциируется с неким окружением, то есть местом, в котором «обитают» люди. Понятие среды в языке программирования (например, Python) довольно похоже. Для Python средой является ваш компьютер. Довольно часто он называется «локальной» средой, поскольку языки могут выполняться и на серверах (компьютеры, которые запускаются в центре обработки данных и доступны через интернет).
Что такое виртуальная среда?
Вы когда-нибудь были в виртуальной реальности или видели, как в ней находился другой человек? Если нет, то вот пример:
Для человека на фотографии выше, окружающей средой становится то, что он видит через очки. Его восприятие окружающей среды меняется на то, что он видит в очках.
В виртуальной среде в Python та же идея: вы предоставляете языку отдельную «среду» внутри вашего компьютера, в которой он будет работать.
Тем не менее между VR-опытом человека и Python есть ряд ключевых различий. Во-первых, вы можете создать несколько виртуальных сред для Python (то есть Python, в отличие от одноликого человека, содержит бесконечное количество лиц, на которые можно надеть сколько угодно VR-очков). Во-вторых, несмотря на то, что человек может ощущать и прикасаться к объектам из «реальной» среды, для Python это вовсе не обязательно. Как только вы надеваете на Python VR-очки, он может (или не может) получать доступ к «реальной» среде (в зависимости от настроек). Таким образом, все библиотеки и пакеты, установленные на компьютере (т.е. в «реальной» среде) не будут доступны в виртуальной среде и наоборот.
Зачем мне это нужно?
Да, звучит круто, но зачем вообще нужна виртуальная среда? Зачем надевать навороченные VR-очки скучным и сложным языкам программирования?
Удобство. Стабильность. Душевный покой. Для вас самих, а не для языка программирования. Вы когда-нибудь замечали, что для разных проектов требуются разные версии библиотек и даже языков программирования? Вот здесь и пригодятся виртуальные среды. Суть в том, что для каждого проекта вы создаете отдельную виртуальную среду.
А поскольку языковые ресурсы (библиотеки, пакеты и др.) скрыты от «реальной» и прочих виртуальных сред, то не возникает никаких конфликтов и помех. Например, вы обновили библиотеку Х в виртуальной среде проекта А. Поскольку вы сделали это внутри виртуальной среды проекта А, то можете быть уверенны, что это не повлечет за собой обновление библиотеки Х в других средах. Таким образом, ваш код и его зависимости в прочих местах останутся неизменными.
Ясно. И как же создать виртуальную среду?
Для этой статьи я воспользуюсь библиотекой virtualenv. Но существует масса других (возможно, более удобных) альтернатив для создания виртуальной среды в Python. Работать буду на Mac — эта система основана на UNIX. Если у вас на компьютере стоит другая система, то этапы могут отличаться.
Возможно, в вашей системе не установлена virtualenv. Проверить это можно через команду:
Если библиотека установлена, терминал выведет ее версию (например, 16.4.3). В противном случае, если вы увидите ошибку «command not found» («команда не найдена»), то введите следующую команду:
PS: Если вдруг у вас отсутствует pip, то скачайте его. Обычно он автоматически включен в бинарные установщики для Python 3.4 и выше.
Следующий шаг — перейдите в директорию, в которой хотите создать виртуальную среду. Можете создать отдельную директорию специально для сред и перейти в нее с помощью этой команды:
Так вы создадите новую папку под названием Environments, а затем сразу же в нее перейдете. Для создания среды введите следующую команду:
Эта команда создает среду project_name внутри текущей рабочей директории. Замените project_name на название своего проекта. По завершении этих шагов окно терминала покажет вам что-то подобное:
Пока что наша виртуальная среда не активирована. Каждый раз, когда вы хотите попасть внутрь среды или активировать ее (т.е. «надеть VR-очки»), нужно выполнять следующую команду:
Тадам! Сейчас вы оказались внутри виртуальной среды! Как же в этом убедиться? Теперь терминал добавляет во все строки префикс project_name:
Вот и все! Вы успешно обучились, создали и активировали виртуальную среду для Python. Можете приступать к работе над проектом внутри среды. Устанавливайте библиотеки, которыми привыкли пользоваться в обычном терминале. Такие библиотеки будут присутствовать только в виртуальной. Выйти из виртуальной среды можно через команду «выхода» :
Виртуальное окружение в Python
В этой статье мы рассмотрим как используется и для чего нужно виртуальное окружение в Python.
Введение
Виртуальное окружение это изолированная пространство для приложений в Python, которое дает возможность иметь свой набор зависимостей не мешая другим проектам.
Так же оно позволяет задействовать различные версии интерпретатора в нескольких проектах.
Создание окружения в Python выполняется с помощью встроенного модуля venv. Venv — это модуль из стандартной библиотеки не требующий никакой дополнительной установки.
Виртуальное окружение создается под конкретные проекты, для его создания потребуется знать путь до корневого каталога.
Создание директории для проекта
Необходимо выполнить команду в терминале
mkdir test_project создает папку с именем test_project, а cd test_project перемещается в эту директорию.
Это то же самое, что создать пустую папку и открыть ее.
В директории test_project будут храниться все файлы проекта и это будет местом для виртуального окружения.
Создание виртуального окружения
Чтобы создать виртуальную среду, нужно вызвать модуль venv из интерпретатора и указать директорию для служебных файлов.
После выполнения будет готово окружение с версией Python по умолчанию.
.venv — имя окружения. Можно называть как угодно. По совместительству является директорией в которой хранится вся информация окружения.
Если в операционной системе есть несколько версий Python и требование использовать какую – то конкретно, создайте виртуальную среду следующим образом
Активация виртуальной среды
Просто создать виртуальное окружение недостаточно, так же его необходимо активировать
Активация виртуальной среды в Windows
Открываем командную оболочку или powershell, переходим в директорию проекта и выполняем команду
Активация виртуальной среды в macOS и Linux
Достаточно открыть терминал в директории проекта и выполнить команду
Активация виртуальной среды изменит приглашение оболочки, чтобы показать, какую виртуальную среду вы сейчас используете.
Вот и все. Затем вы можете установить, обновить и удалить пакеты с помощью pip. Установленные пакеты будут изолированы только для данного проекта.
Заключение
Сегодня мы рассмотрели как используется и для чего необходимо виртуальное окружение в Python. Если у вас есть дополнительные вопросы, не стесняйтесь задавать их в комментариях.
Виртуальные окружения в Python
Python знаменит своей обширной стандартной библиотекой и девизом «батарейки в комплекте» (batteries included). Даже из коробки Python позволяет удобно и быстро решить огромный пласт задач, например, например, работа с файлами, запуск простого веб-сервера, работа с электронной почтой, парсинг XML и JSON, и так далее. Во всяком случае, это намного удобнее, чем писать shell-скрипты 😅
Кроме того, у Python имеется огромная экосистема сторонних библиотек, поддерживаемых сообществом энтузиастов. Эти библиотеки реализуют отсутствующую в стандартной поставке функциональность, либо пере-реализуют уже имеющуюся, но удобнее. Если у вас возникла потребность в какой-то функциональности, то почти наверняка кто-то уже написал для этого библиотеку, и нужно просто погуглить.
Установка сторонней библиотеки
Каждый начинающий программист знает, как установить библиотеку. Набираем
и понеслась! Множество библиотек в своих инструкциях по установке именно так и предлагают их устанавливать. Это и правда работает, это и правда так просто, но есть нюансы. В этом месте закопаны очень популярные грабли, по которым прошлось множество начинающих питонистов, в том числе и я.
Как pip устанавливает пакеты
Давайте разберемся, что же происходит, когда юзер набирает в терминал такую команду. В общих чертах происходит следующее.
Давайте подробнее разберем третий шаг. Установка пакета — звучит загадочно и сложно, но на самом деле ничего сложного здесь не происходит. pip просто распаковывает zip-архив в определенное место (это справедливо для формата wheel, для установки пакетов в других форматах могут потребоваться дополнительные действия, но давайте разберем самый распространённый и простой случай). Куда именно происходит установка? Это можно узнать, выполнив следующую команду:
В списке sys.path можно увидеть директорию site-packages — именно туда и будет установлена библиотека. Давайте в этом убедимся.
До установки пакета:
После установки пакета:
Как видим, в директорию site-packages добавилась библиотека requests вместе со всеми своими зависимостями.
Важные мысли, которые я пытаюсь донести:
А это значит, что в один интерпретатор Python нельзя установить две версии одной библиотеки одновременно. При установке новой версии предыдущая «перезатирается». Просто как если бы вы распаковали другой архив с совпадающими именами файлов в то же самое место.
Боль — это жизненный опыт
Что же будет, если вам понадобится работать над двумя проектами, которые будут требовать разных, не совместимых между собой версий одной и той же библиотеки? Возможно, между этими версиями в библиотеку были внесены какие-то крупные ломающие изменения, например, переименовались методы/функции или изменился набор аргументов.
Вы просто не сможете работать над такими проектами одновременно. Установка зависимостей одного проекта сломает другой, и наоборот. При переключении между проектами придётся каждый раз устанавливать зависимости нужного проекта, что довольно легко забыть сделать.
Ситуация кажется маловероятной, но я гарантирую, что рано или поздно это случится, если устанавливать зависимости всех своих проектов в один интерпретатор. Всё усугубляется тем фактом, что прямые зависимости вашего проекта тянут за собой свои зависимости (под-зависимости), те, в свою очередь, тоже могут от чего-то зависеть (под-под-зависимости). В итоге вы получаете целое дерево зависимостей. И если где-то в этом дереве окажется библиотека не той версии, что ожидалось, то весь проект может начать очень странно работать. Вы получите такие эзотерические ошибки, которых еще никто в интернете до вас не встречал. Если всё сразу сломалось, то считайте, что легко отделались — по крайней мере, так довольно просто понять, в чём проблема. Но бывают и ситуации намного хуже, когда приложение просто начинает немножко иначе работать, без каких-либо ошибок, и возможно придется потратить долгие часы на траблшутинг, чтобы найти настоящую причину.
Надеюсь, я убедил вас, что устанавливать зависимости нескольких проектов в один интерпретатор — это очень-очень плохо. Но как же тогда правильно?
Виртуальные окружения
Как создавать виртуальные окружения
Начиная с Python версии 3.5 (на данный момент это самая старая из официально поддерживаемых версий языка, так что справедливо ожидать, что как минимум везде установлен Python 3.5 или новее), создать виртуальное окружение стало очень просто:
Например, допустим, что мы работаем над проектом blog_source :
В директорию env будет скопирован тот самый интерпретатор, при помощи которого виртуальное окружение и создавалось. Т.е. если
то в виртуальном окружении будет та же самая версия:
Активируем окружение
Посмотрим, что внутри директории env :
Обратите внимание, что в директории bin есть некий файл activate в нескольких вариантах для разных шеллов. Это и есть «точка входа» в виртуальное окружение. Просто создать виртуальное окружение мало, нужно его активировать. Но сначала проверим, какие python и pip (исполняемые файлы) используются в обычном режиме работы:
Это мой обычный Python, вне виртуального окружения, назовём его глобальным. Теперь активируем виртуальное окружение:
Для Windows процесс активации будет отличаться (допустим, что виртуальное окружение создано в C:\src\blog_source ):
Теперь проверим еще раз, какие python и pip используются:
Посмотрите на пути — мы внутри виртуального окружения! Теперь можно смело устанавливать любые пакеты, и это никак не повлияет на глобальный Python или на другие виртуальные окружения:
Можно запускать любые файлы, и они будут иметь доступ к установленным пакетам:
IDE тоже нужно настроить, указав путь к bin/python внутри виртуального окружения, тогда редактор сможет лучше вам помогать.
И мы видим, что команда python снова вызывает глобальный интерпретатор. При этом виртуальное окружение осталось в своей директории, оно просто не активно. В следующий раз, когда будет нужно поработать с виртуальным окружением, не забудьте снова его активировать.
Виртуальное окружение можно полностью удалить, когда оно перестанет быть нужным:
В идеале, у вас должна быть возможность в любой момент удалить и пересоздать виртуальное окружение заново, для этого храните список зависимостей проекта и содержите его в актуальном состоянии (например, в requirements.txt ). В процессе разработки могут случиться всякие казусы с зависимостями, и иногда проще пересоздать виртуальное окружение заново, чем пытаться починить сломанное.
Вот так можно работать с виртуальными окружениями в Python. Всегда устанавливайте зависимости проектов только в изолированные виртуальные окружения. Не смешивайте зависимости разных проектов в одном окружении.
Ничего не устанавливайте в глобальный интерпретатор
Установка начинается, прогресс-бары заполняются, но в итоге всё завершается чем-то типа такого:
Может нарушить целостность системы.
Подробнее про этот метод установки читайте здесь.
установить программу через пакетный менеджер ОС, например:
Выводы
Да, виртуальные окружения — определенно не самая удобная часть разработки на Python, и уж точно не самая простая тема, к этому просто нужно привыкнуть. Несколько раз повторил, выработал привычку — в целом, ничего сложного. Кроме того, экосистема Python развивается очень быстро, и я надеюсь, что скоро правильная установка пакетов и управление виртуальными окружениями станут намного легче. Уже сейчас можно пользоваться такими инструментами, которые в некоторой мере прячут от пользователя виртуальные окружения:
Стабильных вам зависимостей и кода без багов!