Pip в глобальных пакетах сайтов вместо virtualenv

Использование pip3 для установки пакета в virtualenv приводит к тому, что пакет устанавливается в папку ackages глобального сайта -p, а не в папку virtualenv. Вот как я настроил Python3 и virtualenv на OS X Mavericks (10.9.1):

Я установил Python3, используя Homebrew:

ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)"
brew install python3 --with-brewed-openssl

Изменена переменная $PATH в .bash_profile; добавили следующую строку:

export PATH=/usr/local/bin:$PATH

Запуск which python3 возвращает /usr/local/bin/python3 (после перезапуска оболочки).

Примечание: which python3 все еще возвращает /usr/bin/python.

Установлено virtualenv с использованием pip3:

pip3 install virtualenv

Затем создайте новый virtualenv и активируйте его:

virtualenv testpy3 -p python3
cd testpy3
source bin/activate

Примечание. Если я не укажу -p python3, pip будет отсутствовать в папке bin в virtualenv.

Работающие which pip и which pip3 оба возвращают папку virtualenv:

/Users/kristof/VirtualEnvs/testpy3/bin/pip3

Теперь, когда я пытаюсь установить, например, Уценка с помощью pip в активированном virtualenv, pip будет установлена в глобальной папке сайта -p ackages вместо папки сайта -p ackages в virtualenv.

pip install markdown

Запуск pip list возвращает:

Markdown (2.3.1)
pip (1.4.1)
setuptools (2.0.1)
virtualenv (1.11)

Содержание /Users/kristof/VirtualEnvs/testpy3/lib/python3.3/site-packages:

__pycache__/
_markerlib/
easy_install.py
pip/
pip-1.5.dist-info/
pkg_resources.py
setuptools/
setuptools-2.0.2.dist-info/

Содержание /usr/local/lib/python3.3/site-packages:

Markdown-2.3.1-py3.3.egg-info/
__pycache__/
easy-install.pth
markdown/
pip-1.4.1-py3.3.egg/
setuptools-2.0.1-py3.3.egg
setuptools.pth
virtualenv-1.11-py3.3.egg-info/
virtualenv.py
virtualenv_support/

Как видите, папка глобального сайта -p ackages содержит Markdown, а папка virtualenv - нет.

Примечание: у меня были Python2 и Python3, установленные ранее на другой виртуальной машине (следовал этим инструкциям), и у меня была та же проблема с Python3; установка пакетов в Python2 на основе virtualenv работала безупречно.

Любые советы, подсказки,... будет очень признателен.

Ответ 1

Забавно, что ты это сделал, у меня была точно такая же проблема. Я решил это в конечном счете, но я все еще не уверен, что это вызвало.

Попробуйте проверить сценарии bin/pip и bin/activate. В bin/pip посмотрите на shebang. Правильно ли это? Если нет, исправьте это. Затем на линии ~ 42 в bin/activate проверьте, правильно ли ваш виртуальный путь. Это будет выглядеть примерно так.

VIRTUAL_ENV="/Users/me/path/to/virtual/environment"

Если это неправильно, исправьте его, deactivate, затем . bin/activate, и если наша общая проблема имеет ту же причину, она должна работать. В любом случае, если вы этого не сделаете, вы на правильном пути. Я прошел ту же процедуру решения проблем, что и вы, which pip снова и снова, после трассировки стека и т.д.

Убедитесь, что

/Users/kristof/VirtualEnvs/testpy3/bin/pip3

- это то, что вы хотите, и не ссылаетесь на другой аналогично названный тестовый проект (у меня была эта проблема, и я понятия не имею, как это началось. Мое подозрение запускает несколько виртуальных виртуальных машин одновременно).

Если это не работает, может быть временное решение, как сказал Джо Холлоуэй,

Просто запустите виртуальный диск с полным путем (т.е. не полагайтесь на поиск исполняемого пути), и вам даже не нужно активировать среду. Это будет сделано правильно.

Возможно, не идеальный, но он должен работать в крайнем случае.

Ссылка на мой оригинальный вопрос:

VirtualEnv/Pip пытается установить пакеты по всему миру

Ответ 2

Для меня это не проблема с пипсом или virtualenv. Это была проблема с python. Я установил свой $PYTHONPATH вручную в ~/.bash_profile (или ~/.bashrc) после того, как после некоторого обучающего онлайн. Это вручную задано значение $PYTHONPATH было доступно в virtualenv, так как это, вероятно, должно быть разрешено.

Дополнительно add2virtualenv не добавлял мой путь к моему $PYTHONPATH по какой-то причине в virtualenv.

Просто несколько путей разветвления для тех, кто все еще может застрять! Ура!

Ответ 3

У меня была та же проблема, я решил ее, удалив каталог venv и воссоздав его!

deactivate (if venv is activated first deactivate it)
rm -rf venv
virtualenv -p python3 venv
. ENV/bin/activate
pip3 install -r requirements.txt

Теперь все работает как шарм.

Ответ 4

У меня тоже была эта проблема. Вызов pip install <package_name> из каталога /bin в моей виртуальной среде Python 3.3 на моем Mavericks Mac заставил пакет Python быть установленным в каталоге пакетов пакетов Python 2.7. Это было несмотря на то, что моя $PATH началась с каталога, содержащего pip. Weird. Это не происходит в CentOS. Для меня решение вызывало pip3 вместо pip. Когда я установил пик в виртуальную среду через ez_setup, в каталоге /bin были установлены три исполняемых файла "pip" - pip, pip3 и pip3.3. Любопытно, что все три файла были точно такими же. Вызов pip3 install <package_name> привел к тому, что пакет Python был правильно установлен в каталог локальных сайтов. Вызов pip с полным именем пути в виртуальную среду также работал правильно. Мне было бы интересно узнать, почему мой Mac не использует $PATH так, как я ожидал.

Ответ 5

Я попал в ту же проблему при установке пакета python из virtualenv. Основная причина в моем случае была иной. Изнутри virtualenv я (по привычке на Ubuntu), делал:

sudo easy_install -Z <package>

Это заставило игнорировать bin/pip shebang и использовать корневой виртуальный скрипт для установки в глобальных пакетах сайтов. Поскольку у нас есть виртуальная среда, мы должны установить пакет без "sudo"

Ответ 6

Первое, что нужно проверить, - это то, куда адресуется решение:

which pip

Если вы находитесь в виртуальной среде, вы ожидаете, что это даст вам что-то вроде:

/path/to/virtualenv/.name_of_virtualenv/bin/pip

Однако может случиться так, что он по какой-то причине разрешает вашу систему. Например, вы можете увидеть это из своего виртуального (это плохо):

/USR/локальные/бен/пип (или что-либо, что не находится в вашем виртуальном пути).

Чтобы решить эту проблему, выполните команду pipconfig:

~/.pipconf
~/.conf/pip
/etc/pip.conf

и убедитесь, что нет ничего, что принуждает ваш путь к Python или путь к нему (это исправлено для меня).

Затем попробуйте запустить новый терминал и перестроить свой virtualenv (удалить, затем создать его снова)

Ответ 7

У меня была аналогичная проблема после обновления до pip==8.0.0. Пришлось прибегнуть к отладке пипса, чтобы проследить неудачный путь.

Как оказалось, у моего каталога профиля был файл конфигурации distutils с пустым значением пути. Это привело к тому, что все пакеты были установлены в один и тот же корневой каталог вместо соответствующей виртуальной среды (в моем случае /lib/site-packages).

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

Если кто-то еще сталкивается с этой же проблемой, просто удаление файла ~/.pydistutils.cfg (или удаление пустого пути конфигурации) устраняет проблему в моей среде, потому что pip вернулся к распределенной конфигурации по умолчанию.

Ответ 8

Я наткнулся на ту же проблему с Манджаро. Я создал виртуальную среду, используя python3 -m ven venv, а затем активировал, используя source venv/bin/actiave. which python и which pip оба указывали на правильные двоичные файлы в virtualenv, однако я не смог установить на virtualenv даже при использовании полного пути двоичных файлов. Оказалось, что когда я удалил пакет python-pip с sudo pacman -R python-pip python-reportlab (должен был включать reportlab для удовлетворения зависимостей), все начало работать как положено. Не знаю почему, но это, вероятно, связано с двойной установкой, когда системный пакет имеет преимущество.

Ответ 9

Произошла одна и та же проблема. Я просто переустановил pip глобально с помощью sudo easy_install pip (OSX/Max), а затем снова создал свой virtualenv с помощью sudo virtualenv nameOfVEnv. Затем после активации нового virtualenv команда pip работала, как ожидалось.

Я не думаю, что использовал sudo при первом создании virtualenv, и, возможно, это было причиной отсутствия доступа к pip изнутри virtualenv, я смог получить доступ к pip2 до этого исправить, хотя это было странно.

Ответ 10

Вот некоторые методы, которые могли бы избежать головных болей при использовании Виртуальных сред:

  • Создайте папку для ваших проектов.
  • Создайте проекты Virtualenv внутри этой папки.
  • После активации среды вашего проекта никогда не используйте пакет sudo pip install.
  • После завершения вашей работы всегда " деактивировать" вашу среду.
  • Избегайте переименования папки проекта.


Для лучшего представления этих практик, вот симуляция:


создание папки для ваших проектов/сред

$ mkdir venv

создание среды

$ cd venv/ 

$ virtualenv google_drive
New python executable in google_drive/bin/python
Installing setuptools, pip...done.

активирующая среда

$ source google_drive/bin/activate

установка пакетов

(google_drive) $ pip install PyDrive
Downloading/unpacking PyDrive
Downloading PyDrive-1.3.1-py2-none-any.whl
...
...
...    
Successfully installed PyDrive PyYAML google-api-python-client oauth2client six uritemplate httplib2 pyasn1 rsa pyasn1-modules
Cleaning up...

пакет, доступный внутри среды

(google_drive) $ python
Python 2.7.6 (default, Oct 26 2016, 20:30:19) 
[GCC 4.8.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>> import pydrive.auth
>>>  
>>> gdrive = pydrive.auth.GoogleAuth()
>>>

отключить среду

(google_drive) $ deactivate 

$ 

пакет НЕ ДОСТУПНО вне среды

(google_drive) $ python
Python 2.7.6 (default, Oct 26 2016, 20:32:10) 
[GCC 4.8.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>> import pydrive.auth
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named pydrive.auth
>>> 

Примечания:

Почему бы не sudo?

Virtualenv создает для вас совершенно новую среду, определяя $PATH и некоторые другие переменные и настройки. Когда вы используете пакет sudo pip install, вы запускаете Virtualenv как root, избегая создания всей созданной среды и затем устанавливая пакет на глобальных сайтах-пакетах, и не внутри папки проекта, где у вас есть виртуальная среда, хотя вы активировали среду.

Если вы переименуете папку своего проекта (как указано в принятом ответе)...

... вам придется настроить некоторые переменные из некоторых файлов в каталоге bin вашего проекта.

Например:

bin/pip, строка 1 (She Bang)

bin/activate, строка 42 (VIRTUAL_ENV)

Ответ 11

У меня была эта проблема. Оказалось, что в одном из имен моей папки было место, которое вызвало проблему. Я удалил пространство, удалил и восстановил с помощью venv, и все было хорошо.

Ответ 12

Эта проблема возникает при создании экземпляра virtualenv и изменении имени родительской папки.

Ответ 13

Ни одно из вышеперечисленных решений не помогло мне.

Мой венв был активным. pip -V и which pip дал мне правильный путь virtualenv, но когда я pip install pip-пакеты -ed с активированным venv, моя остановка pip freeze осталась пустой.

Все переменные среды тоже были правильными.

Наконец, я просто изменил pip и удалил virtualenv:

easy_install pip==7.0.2

pip install pip==10

sudo pip uninstall virtualenv

Переустановите venv:

sudo pip install virtualenv

Создать венв:

python -m virtualenv venv_name_here

И все пакеты снова правильно установлены в моем venv.

Ответ 14

Перейдите в каталог bin в вашей виртуальной среде и напишите так:

./pip3 install <package-name>

Ответ 15

После создания виртуальной среды попробуйте использовать pip, расположенный в yourVirtualEnvName\Scripts

Следует установить пакет внутри Lib\site-packages в вашей виртуальной среде

Ответ 16

У меня тоже была эта проблема. Вызов sudo pip install привел к тому, что пакеты Python были установлены в глобальном каталоге пакетов, а вызов pip install работал нормально. Поэтому не используйте sudo в virtualenv.

Ответ 17

Та же проблема. Python3.5 и pip 8.0.2 установлены из Linux rpm.

Я не нашел основной причины и не могу дать правильный ответ. Похоже, существует несколько возможных причин.

Однако я надеюсь, что смогу помочь поделиться своим наблюдением и обходным путем.

  • pyvenv с --system-site-packages

    • ./bin не содержит pip, pip доступен из пакетов системных сайтов
    • пакеты устанавливаются глобально (BUG?)
  • pyvenv без --system-site-packages

    • pip устанавливается в ./bin, но это другая версия (от ensurepip)
    • пакеты устанавливаются в виртуальной среде (ОК)

Очевидное обходное решение для pyvenv с --system-site-packages:

  • создайте его без опции --system-site-packages
  • измените include-system-site-packages = false на true в pyvenv.cfg файле

Ответ 18

Также стоит проверить, что вы каким-то образом не изменили путь к вашему virtualenv.

В этом случае первая строка в bin/pip (и остальная часть исполняемых файлов) будет иметь неправильный путь.

Вы можете либо отредактировать эти файлы, либо исправить путь, либо удалить и снова установить virtualenv.

Ответ 19

Для Python 3ers

Попробуйте обновить. У меня была такая же проблема, и я попробовал ответ Чейз, но безуспешно. Самый быстрый способ реорганизовать это - обновить версию Python Minor/Patch, если это возможно. Я заметил, что я запускал 3.5.1 и обновлялся до 3.5.2. Певнов снова работает.

Ответ 20

Это случилось со мной, когда я создал virtualenv в неправильном месте. Затем я подумал, что могу переместить каталог в другое место без какого-либо значения. Это имело значение.

mkdir ~/projects
virtualenv myenv
cd myenv
git clone [my repository]

О, дерьмо, я забыл перейти в projects прежде чем создавать virtualenv и клонировать представителя. Да ладно, мне лень разрушать и воссоздавать. Я просто перенесу каталог без проблем.

cd ~
mv myenv projects
cd projects/myenv/myrepo
pip install -r requirements

Нет, хочет больше разрешений, что? Я думал, что это было странно, но SUDO AWAY! Затем он установил пакеты в глобальное местоположение.

Урок, который я усвоил, был, просто удалите virtualenv dir. Не двигай это.

Ответ 21

Возникла эта проблема после установки Divio: он каким-то образом изменил мой PATH или окружение, так как запускает терминал.

Решением в этом случае было просто сделать source ~/.bash_profile который уже должен быть настроен, чтобы вернуть вас в исходное состояние pyenv/pyenv-virtualenv.

Ответ 22

Каким-то образом файл setup.cfg с префиксом = "" в папке проекта

запуск pip install на virtualenv вне папки проекта работал так, что изнутри он говорил pip использовать пустой префикс по умолчанию "/"

удаление файла исправило это

Ответ 23

Это случилось со мной, когда я установил virtualenv с --python=python3.6 но потом попытался использовать pip2 install.
Создание virtualenv с флагом версии, которую вы будете использовать, решает проблемы с разрешениями. Чтобы проверить, попробуйте which pip which pip2 или which pip3 (зависит от вашего выбора). Если какой - либо pip вы используете показывает путь не venv здесь ваша проблема.

Ответ 24

У меня была эта проблема, и после попытки всего вышеупомянутого решения я просто удалил все и начал заново.

В моем собственном случае я использовал sudo при создании одной из папок, в которой существовала виртуальная среда, и sudo передает привилегии root

Я был очень зол! Но это сработало!

Ответ 25

По какой-то причине я должен использовать 'sudo' для установки пакетов через pip в моей системе Ubuntu. Это приводит к установке пакетов в глобальных пакетах сайта. Положите это здесь для тех, кто может столкнуться с этой проблемой в будущем.

Ответ 26

У меня была именно проблема из названия, и я ее решил. Пип начал устанавливать в пакеты сайта venv после того, как я очистил свой PATH: в самом начале у него был путь к моей локальной директории ~/bin.

Итак, мой совет: тщательно проверяйте переменные среды на предмет "мусора" или каких-либо нестандартных вещей. К сожалению, virtualenv может быть чувствительным к ним.

Удачи!

Ответ 27

Много хорошего обсуждения выше, но были использованы примеры virtualenv. Поскольку "conda" теперь является рекомендуемым инструментом для управления virtualenv, я суммировал шаги по запуску pip в conda env следующим образом.

Я буду использовать py36r в качестве имени env, а /opt/conda/envs - это префикс envs):

$ source/opt/conda/etc/profile.d/conda.sh # пропустить, если уже сделано

$ conda активировать py36r

$ pip install pkg_xyz

$ pip list | grep pkg_xyz

Обратите внимание, что выполняемый пункт должен быть в /opt/conda/envs/py36r/bin/pip (не /opt/conda/bin/pip).

Кроме того, вы можете просто запустить следующее без активации Conda

$/opt/conda/envs/py36r/bin/pip

Также, если вы устанавливаете с помощью conda, вы можете установить без активации:

$ conda install -n py36r pkg_abc...