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

Ответ 1

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

Ответ 2

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

Ответ 3

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

export PYTHONPATH=

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

virtualenv foo
. foo/bin/activate

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

pip freeze

Ответ 7

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

Ответ 8

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

Ответ 9

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

Ответ 10

Я столкнулся с той же проблемой, когда pip в 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. Проверьте местоположение своего пипса и расположение питона и убедитесь, что эти две команды находятся в виртуальной среде

pip --version
which python

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

pip install package_name

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

Ответ 11

Здесь список всех параметров pip 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, и только теперь замораживание 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, то есть любая вещь с пунктом pp - install, freeze, uninstall будет ограничена этим венком и не будет влиять на установку/пакеты Python для глобальных/по умолчанию.

Ответ 12

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

Weird.