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

Question

У меня создалось впечатление, что 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. Кроме того, если я расскажу о том, что для замораживания среды, я получаю множество пакетов. Я бы ожидал, что для новой среды с -no-site-пакетами это будет пустым?

$ 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 ... 

Я не понимаю, как - не-сайт-пакеты должны работать?

Answer 1

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

Answer 2

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

Answer 3

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

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

Answer 4

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

Answer 5

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

Answer 6

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

Answer 7

Вот список всех пунктов установки options - Не найдено ни одной опции «-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, и только теперь задержка цикла не даст список пакетов пакетов 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) перед $ знак указывает, что мы используем виртуальную среду питона т.е. любая вещь с пип - установить, замораживать, деинсталляция будет ограничено этим venv, и не оказывает влияния на глобальную установку Python/по умолчанию/пакеты.

Answer 8

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

Answer 9

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

Странно.

Answer 10

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

Answer 11

Можжевельник получил ответ.

Очистить PYTHONPATH с:

export PYTHONPATH= 

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

virtualenv foo 
. foo/bin/activate 

Только тогда:

pip freeze