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


138

У меня сложилось впечатление, что 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должен работать?


4
К вашему сведению, --no-site-packages устарел. Смотрите здесь
Салем Бен Мабрук

@SalemBenMabrouk Ссылка не работает, новая ссылка здесь. Связанная проблема на Github: флаг '--no-site-packages' недавно исчез?
Ynjxsjmh

В этой ссылке написано, --no-site-packagesчто УСТАРЕЛО. Сохраняется только для обратной совместимости. Отсутствие доступа к глобальным пакетам сайтов теперь является поведением по умолчанию . Если вы хотите получить доступ к глобальным пакетам сайта, вы можете включить --system-site-packages.
Ynjxsjmh

Ответы:


108

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


12
Мой герой! Если вы просто хотите проверить, действительно ли это ваша проблема, вы можете запустить printenv, чтобы увидеть, есть ли PYTHONPATH, и, если это так, запустить unset PYTHONPATH. Вам все равно придется отследить проблему, если вы не хотите, чтобы проблема больше всплывала, но это позволит вам установить новый virtualenv в текущем сеансе оболочки.
UltraBob

Доморощенный делает это тоже!
Роб

1
Хотел бы я поддержать тебя больше. Я заходил на эту страницу более одного раза после того, как натолкнулся на то, что из-за того, что моя PYTHONPATH уже установлена.
Бемму

Я знаю, что это действительно (действительно) старый пост, но я искал везде, в том числе задавал некоторые свои собственные вопросы по SO, и я не могу понять, как приступить --no-site-packagesк работе. Я близок к тому, чтобы просто стереть Ubuntu и посмотреть, исправит ли это что-то. Сначала я думал, что у меня та же проблема с PYTHONPATH, но при беге printenvя ее не вижу. Разочарование растет, и любая помощь очень ценится. Мой sys.path из venv, созданного с помощью, --no-site-packagesкажется, включает в себя все мои каталоги пакетов. Я не знаю, как это изменить. Помогите?
NotAnAmbiTurner

Это также может относиться к вашей глобальной PATHпеременной, если вы также находите исполняемые файлы за пределами virtualenv.
enderland

28

Вы должны убедиться, что вы запускаете 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.


У меня такая же проблема. Интересно, как это произошло, так как при первом вызове pip freeze действительно показывал мне правильные пакеты, но через пару дней он начал вызывать тот, который расположен в / usr / local / bin / ...
jimijazz

1
Это была проблема для меня: я связался pipс определенным путем к глобальному пункту, который не был переопределен при активации virtualenv.
merlinND

1
Вы только что спасли меня, это хорошо сработало для меня (pip3 & python3.7) Спасибо
Саед Юсеф

24

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


2
FWIW, с текущими транковыми версиями pip и virtualenv ваш оригинальный рабочий процесс теперь делает все правильно, во всяком случае, для меня. Тем не менее, я лично все еще избегаю -E и просто устанавливаю pip в каждом virtualenv.
Карл Мейер

17

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

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


Большое вам спасибо за это, я знал, что должен был использовать источник с virtualenv, но не для virtualenvwrapper, и я никогда не слышал о замораживании пипсов.
Еще

ПРАВИЛЬНЫЙ ОТВЕТ. после инициализации virtualenv вы должны активировать его, иначе вы будете использовать системную версию python
AsAP_Sherb

16

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

export PYTHONPATH=

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

virtualenv foo
. foo/bin/activate

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

pip freeze

15

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


1
Для меня, мойка PYTHONPATHс, export PYTHONPATH=казалось, добилась цели.
можжевельник-

4

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


В верхней части сценария должна быть строчка шебанга (начинающаяся с '! #'), Которая будет указывать на интерпретируемую информацию, которая должна быть использована.
wobbily_col

2

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


1

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

Weird.


1

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


1

Я столкнулся с той же проблемой, когда 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
  1. Проверьте местоположение вашего пипса и Python и убедитесь, что эти две команды находятся в виртуальной среде
pip --version
which python
  1. Используйте pip в виртуальной среде для установки пакетов, свободных от глобального прерывания пакетов
pip install package_name

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


0

Вот список всех опций установки 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.


0

Моя проблема была 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
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.