Как удалить виртуальное окружение python в ubuntu

Обновлено: 05.07.2024

Продолжаем серию “ Python .Уроки”. На этот раз мы изучим, что такое виртуальные окружения в Python , зачем они нужны и как их использовать. Познакомимся с инструментами virtualenv и venv для создания виртуальных окружений.

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

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

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

Во-вторых : может возникнуть необходимость в том, чтобы запретить вносить изменения в приложение на уровне библиотек, т.е. вы установили приложение и хотите, чтобы оно работало независимо от того обновляются у вас библиотеки или нет. Как вы понимаете, если оно будет использовать библиотеки из глобального хранилища ( /usr/lib/pythonXX/site-packages ), то, со временем, могут возникнуть проблемы.

В-третьих : у вас просто может не быть доступа к каталогу /usr/lib/pythonXX/site-packages .

ПО позволяющее создавать виртуальное окружение в Python

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

Это, наверное, одни из самых популярных инструментов, позволяющих создавать виртуальные окружения. Он прост в установке и использовании. В сети довольно много руководств по virtualenv , самые интересные, на наш взгляд, будут собраны в конце урока в разделе “Полезные ссылки”. В общем, этот инструмент нужно обязательно освоить, как минимум, потому что описание развертывания и использования многих систем, созданных с использованием Python , включает в себя процесс создания виртуального окружения с помощью virtualenv .

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

virtualenvwrapper

Существуют ещё инструменты и plug-in ’ы, выполняющие работу по изоляции частей системы Python , но мы их не будем рассматривать.

Инструменты, входящие в стандартную библиотеку Python .

Этот модуль появился в Python3 и не может быть использован для решения задачи изоляции в Python2 . По своему функционалу очень похож на virtualenv . Если вы работаете с третьим Python , то можете смело использовать данный инструмент.

virtualenv

Будем рассматривать работу с virtualenv в рамках операционной системы Linux . Для Windows все будет очень похоже, за исключением моментов, связанных со спецификой этой ОС: названия и расположение каталогов, запуск скриптов оболочки и т.п.

Установка virtualenv

Virtualenv можно установить с использованием менеджера pip (ссылка на статью), либо скачать исходные коды проекта и установить приложение вручную.

Установка с использованием pip.

Для установки virtualenv откройте консоль и введите следующую команду:

Установка из исходного кода проекта.

В этом случае, вам нужно будет выполнить чуть большее количество действий.

Введите в консоли следующий набор команд:

Мы рекомендуем вам использовать pip для установки virtualenv .

Создание виртуального окружения

Виртуальное окружение создается следующей командой:

После выполнения данной команды, в текущем каталоге будет создан новый каталог с именем PRG1 . Разберем более подробно его содержимое.

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

Для активации виртуального окружения воспользуйтесь командой (для Linux ):

для Windows команда будет выглядеть так:

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

Если команда выполнилась успешно, то вы увидите, что перед приглашением в командной строке появилась дополнительная надпись, совпадающая с именем виртуального окружения.

virtual environment

При этом в переменную окружения PATH , в самое начало, будет добавлен путь до директории bin , созданного каталога RPG1 .

то в рамках окружения PRG1 вы будите иметь доступ к глобальному хранилищу пакетов:

    • в Linux : /usr/lib/pythonX.X/site-packages
    • в Windows : \PythonXX\Lib\site-packages

    Деактивация виртуального окружения

    Для деактивации виртуального окружения (выхода из него), введите команду deactivate для Linux или deactivate.bat , если вы работаете в Windows .

    virtual environment deactivate

    venv

    Устанавливать venv не нужно, т.к. он входит в стандартную библиотеку Python . Т.е. если вы установили себе Python , то venv у вас уже есть. Помните, что venv работает только в Python3 !

    Создание виртуального окружения

    Для создания виртуального окружения с именем PRG2 с помощью venv выполните следующую команду:

    В результате будет создан каталог PRG2 со структурой похожей на ту, что была описана для virtualenv . Функциональное назначение каталогов тоже самое.

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

    Активация виртуального окружения в Linux выполняется командой:

    Деактивация виртуального окружения

    Деактивация выполняется командой deactivate (работает как в Windows, так и в Linux )

    Полезные ссылки

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

    P.S.


    В данной статье мы рассмотрим, как использовать виртуальную среду для создания и управлять ими отдельно в ваших проектах Python, используя разные версии Python для выполнения, а также рассмотрим, как хранятся и разрешаются зависимости Python.

    Зачем нужна виртуальная среда?

    Python, как и большая часть других современных языков программирования, имеет собственный, уникальный способ загрузки, хранения и разрешения пакетов (или модулей). Это имеет свои преимущества, однако были принятые некоторые интересные решения, на счет хранения и разрешения пакетов, которые привели к определенным проблемам, а именно: как и где эти пакеты хранятся?

    Содержание

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

    Есть вопросы по Python?

    На нашем форуме вы можете задать любой вопрос и получить ответ от всего нашего сообщества!

    Telegram Чат & Канал

    Вступите в наш дружный чат по Python и начните общение с единомышленниками! Станьте частью большого сообщества!

    Паблик VK

    Одно из самых больших сообществ по Python в социальной сети ВК. Видео уроки и книги для вас!

    На Mac OS X, вы можете легко найти, где именно sys.prefix указывает на использование оболочки Python:

    К нашей статье в большей мере относятся сторонние пакеты, установленные при помощи easy_install или pip, обычно располагаются в одном из каталогов, на которую указывает site.getsitepackages:

    '/System/Library/Frameworks/Python.framework/Versions/3.5/Extras/lib/python' ,

    Зачем нам все эти детали?

    Очень важно иметь представление об этом, так как по умолчанию, каждый объект вашей системы будет использовать одинаковые каталоги для хранения и разрешения пакетов (сторонних библиотек. На первый взгляд это не выглядит чем-то значительным. Это так, но только в отношении системных пакетов, являющихся частью стандартной библиотеки Python – но сторонние пакеты – это другое дело.

    Представим следующий сценарий, где у вас есть два проекта: проект А и проект Б, которые оба имеют зависимость от одной и той же библиотеки – проект В. Проблема становится явной, когда мы начинаем запрашивать разные версии проекта В. Может быть так, что проект А запрашивает версию 1.0.0, в то время как проект Б запрашивает более новую версию 2.0.0, к примеру.

    Это большая проблема Python, поскольку он не может различать версии в каталоге «site-packages». Так что обе версии 1.0.0 и 2.0.0 будут находиться с тем же именем в одном каталоге:

    / System / Library / Frameworks / Python .framework / Versions / 3.5 / Extras / lib / python / ProjectC

    И так как проекты хранятся в соответствии с их названиями, то нет различий между версиями. Таким образом, проекты А и Б должны будут использовать одну и ту же версию, что во многих случаях неприемлемо.

    Тут-то и вступает в игру виртуальная среда (вместе с инструментами virtualenv/ven)

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

    В корне своем, главная задача виртуальной среды Python – создание изолированной среды для проектов Python.

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

    И так, в нашем небольшом примере вверху, нам просто нужно создать раздельную виртуальную среду для проектов А и Б. Каждая среда, в свою очередь, сможет зависеть от любой версии проекта В, независимо друг от друга.

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

    Использование виртуальной среды

    Перед тем, как начать: если вы не пользуетесь Python 3, вам нужно будет установить инструмент virtualenv при помощи pip:

    Если вы используете Python 3, у вас уже должен быть модуль venv, установленный в стандартной библиотеке.

    Предположим, что вы пользуетесь последней версией инструмента venv, так как между ним и virtualenv существует несколько различий в отношении команд. По большому счету, это два весьма разных инструмента.

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

    mkdir python - virtual - environments && cd python - virtual - environments

    Создание новой виртуальной среды внутри каталога:

    По умолчанию, это не включает в себя ни один из существующих сторонних пакетов.

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

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

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

    │ └── python3 . 5 -> / Library / Frameworks / Python .framework / Versions / 3.5 / bin / python3 . 5

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

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

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

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

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

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

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

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

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

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

    $ python - c "import bcrypt; print(bcrypt.hashpw('password'.encode('utf-8'), bcrypt.gensalt()))" $ 2b $ 12 $vWa / VSvxxyQ9d .WGgVTdrell515Ctux36LCga8nM5QTW0 . 4w8TXXi

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

    ( env ) $ python - c "import bcrypt; print(bcrypt.hashpw('password'.encode('utf-8'), bcrypt.gensalt()))"

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

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

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

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

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

    / Users / michaelherman / python - virtual - environments / env / bin / python

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

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

    / usr / local / bin : / usr / bin : / bin : / usr / sbin : / sbin : / Users / michaelherman / python - virtual - environments / env / bin : / usr / local / bin : / usr / bin : / bin : / usr / sbin : / sbin :

    В последнем примере, каталог 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:

    Для примера, вы работает с проектом, который требует Django 1.3, которому также необходим проект, который требует Django 1.0 и виртуальные среды в Python дают такую возможность.

    Инструмент virtualenv

    virtualenv устанавливается через pip:

    Создание виртуальной среды Python

    Создаем виртуальную среду для проекта:

    Команда virtualenv venv должен создать папку в текущей директории, в котором должны находиться исполняемые файлы Python и копии библиотек pip, которых вы можете использовать для установки других пакетов. Имя виртуальной среды( в нашем случае, это venv) может быть любым. Если не вводить имя, то все эти выполняемые файлы будут находиться в текущей директории без добавления в подпапку.

    Это создаст копию Python в любой директории, где запустите эту команду, положит его в папку под именем venv.

    Вы также можете использовать версию интерпретатора

    Данная команда будет использовать интерпретатор в директории /usr/bin/python2.7

    Активация виртуальной среды Python

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

    Название текущей виртуальной среды должно появиться в правой части командной строки запроса (т.е. (venv) Your-Computer: your_project UserName$), чтобы вы знали, что она сейчас активна. С текущего момента, любой пакет, который вы установите при помощи pip должен быть перемещен в папку venv, который изолирован от глобальной инсталляции Python.

    Устанавливаем пакеты как обычно:

    Деактивация виртуальной среды Python

    Если вы завершили работу с виртуальной средой, то можете сделать выход из нее, задав команду деактивации

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

    Удаление виртуальной среды Python

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

    Через некоторое время вы, возможно, столкнетесь с множеством виртуальных сред, засоренных в вашей системе, и, возможно, вы забудете их имена или место их размещения.

    Дополнительные замечания

    Заморозка пакетов виртуальной среды Python

    Чтобы ваша среда была последовательной, рекомендуется «заморозить» текущее состояние пакетов среды. Для этого запустите

    Эта команда создаст файл requirements.txt, который будет содержать простой список пакетов в текущей среде и их соответствующие версии. Тем самым, вы сможете посмотреть список установленных пакетов без требуемого формата, используя “pip list”.

    Импорт пакетов виртуальной среды Python

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

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

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

    Инструмент virtualenvwrapper

    virtualenvwrapper предоставляет набор команд, которые делают работу с виртуальными средами более приятным и продуктивным. Он также размещает все ваши виртуальные среды в одном месте.

    Для установки(перед этим проверьте, что у вас установлен virtualenv)

    После этих команд все виртуальные среды будут создаваться в глобальной директории /root/Evns/.

    Для Windows. Для пользователей Windows есть специфичная версия под названием virtualenvwrapper-win.

    В Windows путь path для WORKON_HOME является %USERPROFILE%/Envs

    Создаем среду при помощи команд virtualenvwrapper

    Создание виртуальной среды

    Это создаст папку виртуальной среды venv внутри

    Работа над виртуальной средой при помощи команд virtualenvwrapper

    Альтернативно вы можете создать проект, который создаст виртуальную среду, а также директорию проекта внутри $PROJECT_HOME

    virtualenvwrapper предоставляет таб-завершение на именах среды. Это реально помогает вам, когда у вас много сред и есть вероятность забыть их имена

    Деактивация при помощи команд virtualenvwrapper

    Деактивация по-прежнему остается неизменной

    Удаление при помощи команд virtualenvwrapper

    Другие полезные команды virtualenvwrapper

    1) Список всех сред

    2) Переход в директорию текущей активной среды, так вы сможете увидеть ее site-packages, к примеру

    3) Похож, как и выше, но заходить внутрь site-packages активной текущей среды

    4) Покажет содержимое директории site-packages

    Тут полный список всех остальных полезных команд модуля virtualenvwrapper.

    Инструмент virtualenv-burrito

    С virtualenv-burrito вы можете иметь рабочую комбинированную среду virtualenv + virtualenvwrapper в одной команде.

    Инструмент autoenv

    Модуль autoenv позволяет при переходе в директорию, которая содержит .env автомагически активировать среду.


    И так, что же помогает решить virtualenv?

    Т.к PIP (по умолчанию) ставит все необходимые пакеты глобально в систему. Это хорошо подходит, если используется один проект и он заточен под конкретную версию питона, но если в системе имеется проекты с большим количеством зависимостей, в которых используется что-то тяжелое и ломающее обратную совместимость между релизами.

    Собственно, virtualenv — это тулза, которая позволяет создавать изолированное, виртуальное и переменное окружения с различными пакетами. Такой подход, решает несовместимость версий и вы легко можете переключиться на подходящее переменное окружение и решить проблему.

    Установка virtualenv + virtualenvwrapper в Unix/Linux

    И так, начнем установку virtualenv + virtualenvwrapper на различные ОС. Но прежде чем начнем, необходимо установить python ( разные версии). Кто не знает как это сделать, то вот отличный мануал:

    Я, в данной теме, рассказывал как установить питон с разными версиями.

    Установка virtualenv + virtualenvwrapper в CentOS/Fedora/RedHat

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

    Установка virtualenv + virtualenvwrapper в Debian/Ubuntu

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

    Что касается virtualenvwrapper, то ставим его через PIP.

    Установка virtualenv + virtualenvwrapper в FreeBSD

    Установка virtualenv + virtualenvwrapper в Mac OS X

    Выполним поиск пакетов:

    Чтобы включить автоматическую активацию, добавьте в свой профиль (

    Или, можно сделать это так:

    Установка virtualenv + virtualenvwrapper через PIP

    Для начала, стоит установить сам pip:

    После чего, запускаем:

    PS: можно использовать easy_install (как я собственно и делал):

    Если имеется питон 3, то он ставит pip3. Чтобы установить virtualenv и virtualenvwrapper используйте :

    Использование virtualenv + virtualenvwrapper в Unix/Linux

    Сейчас, я приведу пример того, что используется на моем тестовом сервере. Проверяем версию питона:

    Так же, я установил python 2.7, который находятся:

    Так же, я установил python 3.4, который находятся:

    Собственно сейчас я, создам переменное окружение для питона2 и питона3. Но для начала, нужно все подготовить.

    Настройка virtualenvwrapper в Unix/Linux

    Открываем bashrc для конкретного пользователя:

    Добавляем следующие строки ( можно в самый низ файла):

    В VIRTUALENVWRAPPER_PYTHON переменную, передаем местоположения питона который будет экспортироваться.

    Чтобы использовать Setuptools поверх Ditribute, вы можете установить переменную окружения вашей системы VIRTUALENV_SETUPTOOLS, чтобы Setuptools стал вместо Ditribute:

    Чтобы все изменения вступили в силу, нужно выполнить:

    Использование virtualenv + virtualenvwrapper в Unix/Linux

    При использовании virtualenv.

    Вроде бы работает.

    При использовании virtualenvwrapper.

    Для еще большего комфорта при работе с virtualenv Doug Hellmann написал расширение virtualenvwrapper, которое делает все манипуляции с окружениям еще проще.

    Проверим какая версия используется:

    Сейчас я, создам переменное окружение:

    И создаем ENV сново:

    Чтобы установить в него все необходимое (setuptools, pip, wheel), используйте:

    ИЛИ, выбираем версию python, которая будет использоваться в создаваемом виртуальном окружении и указываем, что мы не будем использовать системные пакеты::

    PS: Чтобы использовать установленные в системе пакеты (если не нашлись в окружении):

    Так же, можно использовать и еще один вариант:

    Чтобы посмотреть список доступных ENV:

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

    Для смены окружение, имеется команда:

    Для перехода в домашнюю директорию данного env, используем:

    Чтобы активировать, используем:

    PS: Думаю не нужно пояснять строку и так все понятно.

    Находясь в окружении, вы можете устанавливать пакеты используя pip:

    Можно сохранить все используемые зависимости в файл:

    Чтобы установить все необходимые зависимости с файла, используйте:

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

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

    Добавить комментарий Отменить ответ

    Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.

    Читайте также: