Virtualenv В Python очень известные инструменты. Почти все учебники рекомендуют вам использовать его. В прошлом я также писал о том, почему вы Не должен использовать систему Python Анкет
Будучи необходимым, начиная с Python 3.4, он был связан с самим Python как Вен модуль.
Нет ничего волшебного в Virtualenv на самом деле. Это просто копия (или символа) для интерпретатора Python, который у вас уже есть в вашей системе, плюс пара других файлов.
Как мы узнали, когда мы, дети, лучший способ выучить и понять вещи – это сломать его или попытаться построить с нуля. Итак, давайте попробуем построить venv/virtualenv без использования встроенного модуля.
Как упоминалось ранее, VirtualEnv – это просто набор каталогов и файлов.
mkdir myenv mkdir myenv/bin
Тогда нам нужно выяснить, где находится интерпретатор System Python.
which python3 /usr/local/bin/python3
Давайте скопим это в нашу “VirtualEnv”:-
cp /usr/local/bin/python3 myenv/bin/
Теперь давайте попробуем вызвать наш «новый» переводчик Python:-
myenv/bin/python3
Мы должны увидеть обычную подсказку, например:-
Python 3.6.0 (default, Jan 24 2017, 16:44:16) [GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>>
Теперь наш «VirtualEnv» получил собственного переводчика, мы также должны убедиться, что у него есть свои собственные Сайт-Пэкиги Справочник, где будут жить все пакеты, которые мы собираемся установить. Это главная причина, по которой мы используем VirtualEnv, так что пакеты, которые мы устанавливаем, не испортились с системным Python или другим проектом VirtualEnv. Запустить myenv/bin/python3 и запустите этот код:-
>>> sys.path ['', '/Library/Frameworks/Python.framework/Versions/3.6/lib/python36.zip', '/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6', '/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload', '/Users/kamal/Library/Python/3.6/lib/python/site-packages', '/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages'] >>> sys.prefix '/Library/Frameworks/Python.framework/Versions/3.6'
Заметьте, что наш Менв Справочник не в выводе. Документы на sys.prefix говорит это:-
Если вступает в силу виртуальную среду, это значение будет изменено в site.py, чтобы указывать на виртуальную среду. Значение для установки Python все еще будет доступно через base_prefix.
И следуя по ссылке на Виртуальная среда это говорит об этом:-
Виртуальная среда – это дерево каталогов, которое содержит исполняемые файлы Python и другие файлы, которые указывают, что это виртуальная среда.
Но что указывает на виртуальную среду? Я немного обманул здесь и создал новый VirtualEnv, используя Python -mvenv tmp_env И в недавно созданном VirtualEnv я заметил файл с именем pyenv.cfg которые содержат это:-
home = /usr/local/bin include-system-site-packages = false version = 3.6.0
Итак, давайте попробуем добавить этот файл в наш VirtualEnv как myenv/pyenv.cfg Анкет После добавления этого файла наш интерпретатор даст следующий вывод:-
>>> import sys >>> sys.path ['', '/Library/Frameworks/Python.framework/Versions/3.6/lib/python36.zip', '/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6', '/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload'] >>> sys.prefix '/Users/kamal/myenv'
Обратите внимание на sys.prefix ценность. Теперь мы на что -то. Это правильно указывало на наш каталог VirtualENV. Однако наш виртуально не в sys.path Анкет Я что -то забыл! Мы до сих пор не создали lib каталог. Итак, давайте сделаем это сейчас:-
mkdir -p myenv/lib/python3.6/site-packages
И проверьте наше sys.path :-
>>> sys.path ['', '/Library/Frameworks/Python.framework/Versions/3.6/lib/python36.zip', '/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6', '/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload', '/Users/kamal/myenv/lib/python3.6/site-packages']
Теперь наше виртуально добавляется в sys.path ! Время установить несколько пакетов:-
myenv/bin/python3 -mpip install requests
Но мы получим следующую ошибку:-
/Users/kamal/myenv/bin/python3: No module named pip
Очевидно, наш Сайт-Пэкиги Справочник по -прежнему пуст, поэтому у нас еще нет PIP. К счастью, получить PIP не так уж и сложно.
wget https://bootstrap.pypa.io/get-pip.py myenv/bin/python3 get-pip.py Collecting pip Using cached https://files.pythonhosted.org/packages/c2/d7/90f34cb0d83a6c5631cf71dfe64cc1054598c843a92b400e55675cc2ac37/pip-18.1-py2.py3-none-any.whl Collecting setuptools Using cached https://files.pythonhosted.org/packages/37/06/754589caf971b0d2d48f151c2586f62902d93dc908e2fd9b9b9f6aa3c9dd/setuptools-40.6.3-py2.py3-none-any.whl Collecting wheel Using cached https://files.pythonhosted.org/packages/ff/47/1dfa4795e24fd6f93d5d58602dd716c3f101cfd5a77cd9acbe519b44a0a9/wheel-0.32.3-py2.py3-none-any.whl Installing collected packages: pip, setuptools, wheel Successfully installed pip-18.1 setuptools-40.6.3 wheel-0.32.3
Теперь у нас есть Pip Установлен, давайте попробуем еще раз установить Запросы :-
myenv/bin/python3 -mpip install requests
На этот раз Запросы будет установлен без проблем. Давайте проверим его в правильном месте:-
myenv/bin/python3 >>> import requests >>> requests
Это правильно, теперь у нас есть полностью функционирующий VirtualEnv!
Проницательный читатель может заметить, что все это далеко, мы ссылались на наш Python как myenv/bin/python3 . Что если мы хотим вызвать это просто как Python3 ? В Virtualenv есть концепция активировать что вы делаете после того, как создали новую Env. Это в основном добавляя недавно созданный каталог ENV в Путь переменная среды, которая представляет собой список пути поиска, используемый оболочкой ОС, чтобы найти, где существует конкретная программа. активировать Скрипт в основном выглядит так:-
OLD_PATH=$PATH PATH=`pwd`/myenv/bin:$PATH
К деактивировать , мы заменяем Путь Вернуться к Old_path Анкет
В качестве альтернативы, мы также можем запустить подборную с пути, содержащего новый путь:-
PATH=`pwd`/myenv/bin:$PATH sh
И деактивировать, мы просто Выход из подборной. Лично я не рекомендую это «активировать». Я предпочитаю призывать прямого интерпретатора VirtualENV, используя его полный путь.
Оригинал: “https://dev.to/k4ml/python-diy-virtualenv-5e4j”