Создание venv python linux

Python venv: how to create, activate, and delete

Last updated on October 9, 2021

Let’s look at how to use the Python venv, short for Python virtual environment or virtualenv. You will learn how to create a venv, activate and deactivate it, delete it, and how a venv works internally. If you want to know why a venv is so useful, please read our introduction page on virtual environments first.

Table of contents

Creating a Python venv

There are several ways to create a Python virtual environment, depending on the Python version you are running.

Before you read on, I want you to point you to another tool, called pipenv. It combines the functionality of tools that you are about to learn; virtualenv and pip. Further on in this chapter, I will describe pipenv in detail.

Python 3.4 and above

If you are running Python 3.4+, you can use the venv module baked into Python:

This command will create a venv in the specified directory and copy pip and easy_install into it too.

All other Python versions

The alternative that works for any Python version is using the virtualenv package. You may need to install it first, system-wide, with:

Once installed, you can create a virtual environment with:

Python venv activation

Linux and MacOS venv activation

On Linux and MacOS, we activate our virtual environment with the source command. If you created your venv in the myvenv directory, the command would be:

Windows venv activation

To activate your venv on Windows, you need to run a script that gets installed by venv, like so:

That’s it! We’re ready to rock! You can now install packages with pip, but I advise you to keep reading to understand the venv better first. Hang tight, as we’ll get to pip very soon.

How a Python venv works

When you activate a virtual environment, your PATH variable is changed. On Linux and MacOS, you can see it for yourself by printing the path with echo $PATH . On Windows, use echo %PATH% . In my case, on Windows, it looks like this:

As you can see, the bin directory of my venv is put in front of everything else, effectively overriding all the system-wide Python software. This works because when you enter a command that can’t be found in the current working directory, your OS starts looking at all the paths in the PATH variable. If your venv is there first, the OS will look there first before looking at system-wide directories like /usr/bin .

If you take a look inside the directory of your venv (in this case: myvenv ), you’ll see something like this:

Virtualenv directory tree

You can see that:

• The Python command is made available both as python and python3 , and the version is pinned to the version with which you created the venv by creating a symlink to it.
• All packages you install end up in the site-packages directory.
• We have activation scripts for multiple shell types (bash, csh, fish)
• Pip is available under the names pip and pip3

Deactivate the Python venv

Once you finished working on your project, it’s a good habit to deactivate its venv. Without deactivating it, all other Python code you execute will also run inside of it.

Luckily, deactivating your virtual environment couldn’t be simpler. Just enter this: deactivate . It works the same on all operating systems.

Deleting a Python venv

You can completely remove a virtual environment, but how you do that depends on what you used to create the venv. Let’s look at the most common options.

Delete a venv created with Virtualenv or python -m venv

There’s no special command to delete a virtual environment if you used virtualenv or python -m venv to create your virtual environment, as is demonstrated in this article. When creating the virtualenv, you gave it a directory to create this environment in.

If you want to delete this virtualenv, deactivate it first and then remove the directory with all its content. On Unix-like systems and in Windows Powershell, you would do something like:

Delete a venv with Pipenv

If you used Pipenv, you can use the following command to delete the current venv:

Make sure you are inside the project directory. In other words, the directory where the Pipenv and Pipenv.lock files reside. This way, pipenv knows which virtual environment it has to delete.

If this doesn’t work, you can get a little nastier and manually remove the venv. First ask pipenv where the actual virtualenv is located, with the following command:

It will output the path to the virtual environment and all of its files, and it will look similar to the example above. The next step is to rm -rf that entire directory and you’re done.

Delete a venv with Poetry

If you created the virtualenv with Poetry, you can list the available venv’s with the following command:

You’ll get a list like this:

You can remove the environment you want with the poetry env remove command. You need to specify the exact name from the output above, for example:

Keep learning

• Learn how to install packages with pip inside your venv
• Pipenv is a better way of managing your venv and packages. However, I recommend first reading about Pip!
• Official venv documentation: If you want to know all the details and command-line options

About the author

Erik van Baaren

Erik is the owner of Python Land and the author of many of the articles and tutorials on this website. He’s been working as a professional software developer for 25 years, and he holds a Master of Science degree in computer science. His favorite language of choice: Python!

Источник

Питон в коробке – venv в python 3.3

Наверняка, большинство из тех, кто разрабатывает или деплоит Python приложения, использует виртуальные окружения. В частности через virtualenv, написанный Ian Bicking.

Идея оказалась так хороша и распространена, что нечто похожее теперь присутствует в Python 3.3 из коробки в виде модуля venv. Он почти такой же, как virtualenv, только немного лучше.

Как это работает?

Основное отличие venv в том, что он встроен в интерпретатор и может отрабатывать ещё до загрузки системных модулей. Для этого, при определении базовой директории с библиотеками, используется примерно такой алгоритм:

• в директории с интерпретатором или уровнем выше ищется файл с именем pyvenv.cfg ;
• если файл найден, в нём ищется ключ home, значение которого и будет базовой директорией;
• в базовой директории идёт поиск системной библиотеки (по спец. маркеру os.py );
• если что-то пошло не так – всё откатывается к захардкоженному в бинарнике значению.

Вот и вся суть venv, всё остальное уже обёртка над этим.

Как создать?

Всё очень просто, нужно вызвать через ключ -m модуль venv , либо использовать встроенный скрипт pyvenv:

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

При создании можно добавлять различные параметры, как, например, включение системных site-packages или использование symlink вместо копирования интерпретатора.

В отличии от virtualenv новый venv требует чтобы создаваемая директория не существовала, либо была пустой. Вероятно, это сделано, чтобы не допускать конфликтов с существующими файлами. Это бага в python 3.3, в 3.4 уже исправлено. (Спасибо, svetlov).

Как использовать?

Можно использовать старый добрый метод активации через bin/activate (Scripts/activate в windows):

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

Это конечно не сработает для скриптов, запускаемых напрямую через #!/usr/bin/env python3 , для них всё равно нужно будет, как и раньше, делать активацию. Решение есть – о нём чуть ниже.

Обновление

Если в вашей системе обновилась версия python, то виртуальное окружение иногда тоже нужно обновить.
Всё просто – вызываем venv аналогично созданию окружения, добавив ключ —upgrade :

Это произойдёт автоматически, если использовать symlink, но если вы хотите кроме изоляции делать фиксацию версии python и библиотек, я бы рекомендовал делать обновление вручную.

Расширение EnvBuilder

Вся работа по созданию окружения падает на класс venv.EnvBuilder , этот класс написан так, чтобы его можно было расширять.

Например, можно при инициализации окружения ставить туда distribute , pip и необходимые начальные зависимости из requirements.txt . Более сложную логику лучше оставить на совести более предназначенных для этого инструментов, типа buildout или make, но первоначальную настройку можно провести и на уровне EnvBuilder.

При создании окружения используется метод create(self, env_dir) , в исходном классе он выглядит так:

Метод описывает суть всего процесса: создание директории ( ensure_directories ), конфигурацию ( create_configuration ), добавление бинарников питона ( setup_python ) и добавление скриптов активации ( setup_scripts ).

В конце вызывается хук post_setup , в который вы можете добавлять свои действия. Видно, что post_setup выполняется только при создании окружения, а при — upgrade он выполняться не будет. Это легко исправить, добавив ещё один хук:

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

• context.bin_path — путь к директории с бинарниками и исполняемыми скриптами,
• context.env_dir — путь к директории с созданным окружением,
• context.env_exe — путь к бинарнику внутри окружения.

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

Исполняемые скрипты внутри venv

Вернёмся к проблеме с исполняемыми скриптами внутри виртуального окружения.

В virtualenv для них достаточно было указать интерпретатор через #/usr/bin/env python3 и использовать, не забывая сделать . bin/activate . Если вас такой подход устраивал, то вы можете им продолжать пользоваться и в venv .

Есть и новый путь. Внутри EnvBuilder реализован метод install_scripts(self, context, path) , который автоматизирует копирование скриптов и бинарников в создаваемое окружение. В path необходимо передать путь к директории с вложенными поддиректориями «common», «nt», «posix» и т.д. В поддиректории, в свою очередь, положить необходимые скрипты или бинарники. В «common» скрипты для всех платформ, в «nt» – для Windows, «posix» – для Linux, Mac OS X и других posix систем.

Кроме того, для текстовых файлов выполняется постановка значений. Из коробки поддерживаются:

• __VENV_DIR__
• __VENV_NAME__
• __VENV_BIN_NAME__
• __VENV_PYTHON__

Пример шаблона запускаемого python скрипта:

__VENV_PYTHON__ будет заменено на полный путь к интерпретатору python в виртуальном окружении.

После установки такого скрипта через install_scripts , его можно будет запускать, без необходимости активации окружения через bin/activate.

Источник

Виртуальное окружение 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

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

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

Деактивация

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

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

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

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

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

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

Источник