Виртуальное окружение Python (venv)

В се сторонние пакеты устанавливаются менеджером PIP глобально. Проверить это можно просто командой pip show

# pip3 show pytest Name: pytest Version: 5.3.2 Summary: pytest: simple powerful testing with Python Home-page: https://docs.pytest.org/en/latest/ Author: Holger Krekel, Bruno Oliveira, Ronny Pfannschmidt, . License: MIT license Location: /usr/local/lib/python3.8/site-packages Requires: more-itertools, pluggy, py, wcwidth, attrs, packaging Required-by:

Location – путь до ваших глобальных пакетов.

В большинстве случаев, устанавливать пакеты глобально – плохая идея 🙅‍♂️ Почему? Рассмотрим простой пример:

Допустим у нас есть два проекта: » Project A» и » Project B» . Оба проекта зависят от библиотеки Simplejson . Проблема возникает, когда для «Project A» нужна версия Simplejson 3.0.0, а для проекта «Project B» – 3.17.0. Python не может различить версии в глобальном каталоге site-packages – в нем останется только та версия пакета, которая была установлена последней.

Решение данной проблемы – создание виртуального окружения (virtual environment)

Основная цель виртуального окружения Python – создание изолированной среды для python-проектов.

Это означает, что каждый проект может иметь свои собственные зависимости, независимо от других проектов.

Настройка виртуального окружения

Один из самых популярных инструментов для создания виртуального окружения – virtualenv . Однако в данной статье мы будем рассматривать более свежий инструмент venv .

Устанавливать venv не нужно – он входит в стандартную библиотеку Python

Создание

Для создания виртуального окружения, перейдите в директорию своего проекта и выполните:

python -m venv venv

Флаг -m указывает Python-у запустить venv как исполняемый модуль. venv/ — название виртуального окружения (где будут храниться ваши библиотеки)

В результате будет создан каталог venv/ содержащий копию интерпретатора Python, стандартную библиотеку и другие вспомогательные файлы.

Новые пакеты будут устанавливаться в venv/lib/python3.x/site-packages/

Активация

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

• venv\Scripts\activate.bat — для Windows;
• source venv/bin/activate — для Linux и MacOS:

source выполняет bash-скрипт без запуска дополнительного bash-процесса.

Проверить успешность активации можно по приглашению оболочки. Она будет выглядеть так:

Также новый путь до библиотек можно увидеть выполнив команду:

python -c «import site; print(site.getsitepackages())» Интересный факт: в виртуальном окружении вместо команды python3 и pip3, можно использовать python и pip

Автоматическая активация

В некоторых случаях, процесс активации виртуального окружения может показаться неудобным (про него можно банально забыть 🤷‍♀️ )

На практике, для автоматической активации перед запуском скрипта, создают скрипт-обертку на bash

#!/usr/bin/env bash source $BASEDIR/venv/bin/activate python $BASEDIR/my_app.py

Теперь можно установить права на исполнение и запустить нашу обертку:

chmod +x myapp/run.sh ./myapp/run.sh

Деактивация

Закончив работу в виртуальной среде, вы можете отключить ее, выполнив консольную команду:

Альтернативы venv

На данный момент существует несколько альтернатив для venv:

• pipenv — это pipfile, pip и virtualenv в одном флаконе;
• pyenv — простой контроль версий Питона;
• poetry — новый менеджер для управления зависимостями;
• autoenv — среды на основе каталогов;
• pew — инструмент для управления несколькими виртуальными средами, написанными на чистом Python;
• rez — интегрированная система конфигурирования, сборки и развертывания пакетов для программного обеспечения.

Стоит ли использовать виртуальное окружение в своей работе – однозначно да. Это мощный и удобный инструмент изоляции проектов друг от друга и от системы. С помощью виртуального окружения можно использовать даже разные версии Python!

Однако рекомендуем присмотреться к более продвинутым вариантам, например к pipenv или poetry .

Virtualenv (sourse не является внутренней или внешней командой)

Python не является внутренней или внешней
Господа объясните дурачку что делать,если “”python“ не является внутренней или внешней командой.

Python не является внутренней или внешней командой
Добавил в переменную path путь к питону, точнее к скриптам, но ничего не выходит, кс до сих пор.

«python» не является внутренней или внешней командой, исполняемой программой или пакетным файлом
Здравствуйте, не могу запустить питон, при записи в командную строку python ошибка :»python» не.

Заказываю контрольные, курсовые, дипломные и любые другие студенческие работы здесь или здесь.

Не является внутренней или внешней командой
Подскажите, из-за чего возникает проблема с «любая команда bat» не является внутренней или внешней.

Else не является внутренней или внешней командой
Здравствуйте, недавно захотелось создать батник по оптимизации ПК(я в этом деле новичок, не судите.

qmake не является внутренней или внешней командой
При попытке собрать библиотеку выдает «qmake не является внутренней или внешней командой». Что-то.

Ошибка: не является внутренней или внешней командой исполняемой программой
не является внутренней или внешней командой исполняемой программой Что делать?

Как подружиться с виртуальным окружением Python

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

Если вы минималист

Можно установить библиотеку virtualenv в базовую сборку Python. Затем посредством данного инструмента создавать и активировать виртуальные окружения. Фактически это подразумевает копирование базовых компонентов Python в отдельную папку и настройку среды для поддержки дальнейшей работы только с их использованием. Итак, проделаем эти шаги:

1. pip install virtualenv — установка virtualenv ;
2. mkdirnew_project — создание папки с именем new_project ;
3. cdnew_project — переход в папку;
4. virtualenvnew_project_env — создание виртуальной среды с именем new_project_env в папке new_project ;
5. sourcenew_project_env/bin/activate (или new_project_env\Scripts\activate — в Windows ) — активация виртуальной среды;
6. работа с проектом;
7. deactivate — деактивация виртуальной среды и завершение работы с ней.

Первые 4 шага требуются только в момент первоначальной настройки, а последующая работа с проектом ограничивается активацией (не забудьте указать путь до activate в шаге 5) и деактивацией среды.

Другим вариантом работы является создание разных виртуальных окружений в одной папке (не той, в которой создался новый проект). Это удобно, если вы хотите разделить одно виртуальное окружение между несколькими проектами. Отличием данного варианта будет то, что шаг 2 каждый раз осуществлять не нужно, достаточно перейти в папку с виртуальными окружениями (конечно, если ее еще нет, то сначала создать) и пройти этапы 4-7.

Давайте убедимся, что после активации среды изменяется путь до используемого по умолчанию интерпретатора:

which отображает полный путь к командам или сценариям. После активации среды адрес до интерпретатора и менеджера пакетов изменился, соответственно, любые новые модули будут устанавливаться и исполняться в виртуальном окружении. Для интереса выведем содержимое переменной окружения $Path, хранящей пути поиска файлов, до и после активации виртуального окружения Python:

Обратите внимание на тот факт, что первый путь до интерпретатора Python (в сборке Anaconda) заменяется аналогичным адресом из виртуального окружения. Отмечу, что в примере выше использовался новый способ активации виртуальной среды, о котором рассказывается чуть ниже.

Если вы используете популярную сборку Anaconda

В этом случае в вашем распоряжении менеджер пакетов conda, с помощью которого можно создать, активировать и деактивировать виртуальное окружение.

Для создания задаем имя среды и предпочитаемую версию python.

Таким способом виртуальное окружение создается в отдельной папке с относительным адресом anaconda3/envs.

Также виртуальное окружение можно создать с использованием графического инструмента Anaconda Navigator (подробнее читай здесь ).

Для активации и деактивации достаточно набрать

Если вы используете средство управления виртуальными средами virtualenvwrapper

Для его добавления к базовой сборке следует набрать:

pip install virtualenvwrapper

Далее следует этап загрузки переменных и функций virtualenvwrapper , для чего запускаем сценарий virtualenvwrapper.sh (в Windows работает только в оболочке Git-Bash):

Для создания виртуальной среды можно воспользоваться командой:

mkvirtualenv —python=python3.8 имя_окружения

По умолчанию виртуальное окружение создается в подпапке .virtualenvs домашней директории. Активация происходит посредством следующей команды:

Резюмируя отмечу, что для крупных проектов, предполагающих установку специфических библиотек, лучше создавать отдельные виртуальные окружения, в то время как ряд малых и схожих могут использовать общее окружение.
Большим преимуществом использования виртуальных окружений помимо решения проблем совместимости библиотек является поддержка базовой сборки 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 базируется в новой виртуальной среде.

Начиная с Python 3.3 и 3.4, рекомендуемый способ создания виртуального пространства – это использование инструмента командной строки pyvenv, который также включен в инсталляцию вашего Python 3 по умолчанию. Однако, в версии 3.6 и выше, вам нужен python3 -m venv.

В примере выше, эта команда создает каталог под названием «env», структура каталога которого схожа со следующей:

Что находится в этих папках?

• bin – файлы, которые взаимодействуют с виртуальной средой;
• include – С-заголовки, компилирующие пакеты Python;
• lib – копия версии Python вместе с папкой «site-packages», в которой установлена каждая зависимость.

Далее, у нас есть копии или символические ссылки нескольких различных инструментов Python. Эти файлы используются для обеспечения того, чтобы команды и код Python выполнялись в контексте нынешней среды, таким образом, достигается изоляция от глобальной среды. Мы рассмотрим это детальнее в следующем разделе.

Более интересные сейчас – скрипты activate в папке bin. Эти скрипты используются для настройки вашей оболочки для использования исполняемого файла среды Python и его сайтовых пакетов по умолчанию.

Чтобы использовать эти пакеты (или ресурсы) среды в изоляции, вам нужно «активировать» их. Чтобы сделать это, просто запустите:

Обратите внимание на то, что ваше приглашение командной строки теперь носит префикс вашей среды (в нашем случае – env). Это индикатор того, что env в данный момент активен, что в свою очередь говорит о том, что выполнимые файлы Python используют пакеты и настройки только этой среды.

Чтобы показать изолированный пакет в действии, мы можем использовать модуль bcrypt в качестве примера. Скажем, что модуль bcrypt установлен где-нибудь в системе, но не в нашей виртуальной среде.

Перед тем как проверить это, нам нужно вернуться назад в контекст «system» , выполнив команду deactivate:

Теперь ваш сеанс оболочки вернулся в норму, а команда python ссылается на общую установку Python. Помните: это можно делать когда угодно, после закрытия определенной виртуальной среды.

Теперь установим bcrypt и используем его для хеширования пароля:

Что произойдет, если мы попробуем ту же команду, когда виртуальная среда активна?

Как мы видим, поведение команды the python -c «import bcrypt…» меняется после вызова источника env/bin/activate.

В одном примере, у нас есть доступный нам bcrypt, а в другом его нет. Это тот тип разделения, который мы ищем для виртуальной среды, и мы к нему пришли.

Как работает виртуальная среда?

Что именно имеется ввиду под «активировать» среду? Понимание того, что именно происходит под капотом, может быть очень важно для разработчика, особенно когда вам нужно понять выполнение виртуальной среды, разрешение зависимостей, и так далее.

Чтобы объяснить, как это работает, для начала проверим расположения разных исполняемых файлов python. С «деактивированной» средой запускаем:

Теперь активируем и снова запустим команду:

Активировав среду, мы теперь получаем другой путь к исполнимому файлу python, так как в активной среде, переменная среды $PATH несколько отличается.

Обратите внимание на разницу между первым путем в $PATH до и после активации:

В последнем примере, каталог bin нашей виртуальной среды теперь находится в начале пути. Это значит, что это первый каталог в поиске, когда мы запускаем исполняемый файл в командной строке. Таким образом, оболочка использует экземпляр нашей виртуальной среды в Python, а не в системной версии.

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

Это наталкивает на вопросы:

• В чем разница между этими исполняемыми файлами?
• Каким образом виртуальная среда исполняемого файлаPython может использовать что-либо, кроме системных сайт-пакетов?

Это можно объяснить тем, как 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: