virtualenv --no-site-packages и pip все еще находят глобальные пакеты?

У меня сложилось впечатление, что virtualenv --no-site-packagesэто создаст совершенно отдельную и изолированную среду Python, но, похоже, это не так.

Например, у меня есть python-django, установленный глобально, но я хочу создать virtualenv с другой версией Django.

$ virtualenv --no-site-packages foo       
New python executable in foo/bin/python
Installing setuptools............done.
$ pip -E foo install Django
Requirement already satisfied: Django in /usr/share/pyshared
Installing collected packages: Django
Successfully installed Django

Из того, что я могу сказать, pip -E foo installвышеизложенное должно переустановить новую версию Django. Также, если я скажу pip заморозить среду, я получу много пакетов. Я ожидаю, что для свежей среды с --no-site-packagesэтим будет пустым?

$ pip -E foo freeze
4Suite-XML==1.0.2
BeautifulSoup==3.1.0.1
Brlapi==0.5.3
BzrTools==1.17.0
Django==1.1
... and so on ...

Я неправильно понимаю, как --no-site-packagesдолжен работать?

У меня была такая проблема, пока я не понял, что (задолго до того, как я обнаружил virtualenv), я добавил каталоги к PYTHONPATH в своем файле .bashrc. Поскольку это было более года назад, я не думал об этом сразу.

Вы должны убедиться, что вы запускаете pipдвоичный файл в виртуальной среде, которую вы создали, а не в глобальной.

env/bin/pip freeze

Смотрите тест:

Мы создаем virtualenv с --no-site-packagesопцией:

$ virtualenv --no-site-packages -p /usr/local/bin/python mytest
Running virtualenv with interpreter /usr/local/bin/python
New python executable in mytest/bin/python
Installing setuptools, pip, wheel...done.

Мы проверяем вывод freezeвновь созданного pip:

$ mytest/bin/pip freeze
argparse==1.3.0
wheel==0.24.0

Но если мы используем глобальный pip, это то, что мы получаем:

$ pip freeze
...
pyxdg==0.25
...
range==1.0.0
...
virtualenv==13.1.2

То есть все пакеты, которые pipустановлены во всей системе. Проверяя, which pipмы получаем (по крайней мере, в моем случае) что-то вроде того /usr/local/bin/pip, что означает, что когда мы делаем pip freezeэто, мы вызываем этот двоичный файл вместо mytest/bin/pip.

В конце концов я обнаружил, что по какой-то причине пип-Э не работает. Тем не менее, если я на самом деле активирую virtualenv и использую easy_install, предоставляемый virtualenv, для установки pip, а затем использую pip непосредственно изнутри, кажется, что он работает должным образом и показывает пакеты только в virtualenv.

Я знаю, что это очень старый вопрос, но для тех, кто прибывает сюда в поисках решения:

Не забудьте активировать virtualenv ( source bin/activate) перед запуском pip freeze. В противном случае вы получите список всех глобальных пакетов.

Временно очистите с PYTHONPATHпомощью:

export PYTHONPATH=

Затем создайте и активируйте виртуальную среду:

virtualenv foo
. foo/bin/activate

Только затем:

pip freeze

--no-site-packagesследует, как следует из названия, удалить стандартный каталог site-packages из sys.path. Все остальное, что живет в стандартном пути Python, останется там.

Аналогичная проблема может возникнуть в Windows, если вы вызываете сценарии напрямую, script.pyкоторые затем используют средство открытия Windows по умолчанию и открывают Python вне виртуальной среды. Вызов с помощью python script.pyбудет использовать Python с виртуальной средой.

Это также происходит, когда вы перемещаете каталог virtualenv в другой каталог (в linux) или переименовываете родительский каталог.

У меня была такая же проблема. Проблема для меня (в Ubuntu) заключалась в том, что мой путь содержал имя $. Когда я создал virtualenv за пределами $ dir, он работал нормально.

Weird.

Одна из возможных причин, почему virtualenv pip не будет работать, заключается в том, что в какой-либо из родительских папок было место в имени, /Documents/project name/app переименовывая его для /Documents/projectName/appрешения проблемы.

Я столкнулся с той же проблемой, когда pip in venv по-прежнему работает как глобальный pip.
После поиска многих страниц, я понимаю это таким образом.
1. Создайте новый venv с помощью virtualenv с опцией "--no-site-packages"

virtualenv --no-site-packages --python=/xx/xx/bin/python my_env_nmae

обратите внимание, что хотя опция «--no-site-packages» была по умолчанию true, начиная с 1.7.0 в doc-файле virtualenv, но я обнаружил, что она не работает, если вы не включили ее вручную. Чтобы получить чистый венв, я настоятельно рекомендую включить эту опцию 2. Активировать созданный вами новый env

source ./my_env_name/bin/activate

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

pip --version
which python

4. Используйте pip в виртуальной среде для установки пакетов, свободных от глобального прерывания пакетов

pip install package_name

Желаю, чтобы этот ответ помог вам!

Вот список всех опций установки pip - я не нашел ни одной -Eопции, возможно, она была в более старой версии. Ниже я делюсь простым использованием английского языка и работой virtualenvдля будущих пользователей SO.

Кажется, все хорошо, примите активацию virtualenv( foo). Все, что он делает, - это позволяет нам иметь несколько (и разную) среду Python, то есть различные версии Python, или различные версии Django, или любой другой пакет Python - в случае, если у нас есть предыдущая версия в производстве и мы хотим протестировать последнюю версию Django с нашим применение.

Короче говоря, создание и использование (активация) виртуальной среды ( virtualenv) позволяет запускать или тестировать наше приложение или простые сценарии Python с другим интерпретатором Python, т.е. Python 2.7 и 3.3 - может быть новой установкой (с использованием --no-site-packagesопции) или всеми пакетами из существующих / последняя настройка (используя --system-site-packagesопцию). Чтобы использовать это, мы должны активировать это:

$ pip install djangoустановит его в глобальные пакеты сайтов и аналогичным образом pip freezeполучит имена глобальных пакетов сайтов.

в то время как внутри venv dir (foo) при выполнении $ source /bin/activateактивирует venv, т.е. теперь все, что установлено с помощью pip, будет установлено только в виртуальном env, и только теперь замораживание pip не выдаст список глобальных пакетов python для пакетов сайта. После активации:

$ virtualenv --no-site-packages foo       
New python executable in foo/bin/python
Installing setuptools............done.
$ cd foo
$ source bin/activate 
(foo)$ pip install django

(foo)до того, как $знак укажет, что мы используем виртуальную среду Python, т.е. любая вещь с pip - install, freeze, uninstall будет ограничена этим venv и не повлияет на глобальные / стандартные установки / пакеты Python.

Моя проблема была pipи python3версии. Для последней версии djangoустановки, pip3необходимо. Поэтому моя проблема была решена после создания виртуальной среды с помощью следующих команд:

> virtualenv --python=python3 venv
> source venv/bin/activate
> which pip3 #should be different from /usr/local/bin/pip3
...<some-directory>/venv/bin/pip3