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

Использование pip3для установки пакета в a virtualenvприводит к тому, что пакет устанавливается в глобальную папку site-packages, а не в папку 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

Теперь, когда я пытаюсь установить, например, Markdown, используя pip в активированном virtualenv, pip будет устанавливаться в глобальной папке site-packages вместо папки site-packages в 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/

Как видите, папка global site-packages содержит Markdown, а папка virtualenv - нет.

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

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

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

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

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

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

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

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

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

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

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

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

Ссылка на мой исходный вопрос:

VirtualEnv / Pip пытается установить пакеты глобально

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

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

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

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

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

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

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

Первое, что нужно проверить, это то, к какому местоположению разрешается точка:

which pip

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

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

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

/ usr / local / bin / pip (или что-нибудь, что не находится на вашем пути virtualenv).

Чтобы решить эту проблему, проверьте свой pipconfig в:

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

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

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

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

sudo easy_install -Z <package>

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

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

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

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

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

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

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

./pip3 install <package-name>

У меня была такая же проблема на macos с установленным python 2 и 3.

Кроме того, у меня были псевдонимы, указывающие на python3 и pip3 в моем .bash_profile.

alias python=/usr/local/bin/python3
alias pip=/usr/local/bin/pip3

Устранена python3 -m venv venvпроблема с удалением псевдонимов и воссозданием виртуального окружения .

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

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

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

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

Чтобы лучше представить эту практику, вот симуляция:

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

$ 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 , вы запускаете Virtualenv как root , избегая всей созданной среды, а затем устанавливая пакет в глобальных пакетах сайтов, а не внутри папки проекта, где у вас есть виртуальная среда, хотя вы активировали среду.

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

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

Например:

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

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

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

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

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

Мой венв был активен. pip -Vи which pipдал мне правильный путь virtualenv, но когда я pip install-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

Создайте venv:

python -m virtualenv venv_name_here

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

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

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

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

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

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

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

1. pyvenv с участием --system-site-packages

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

2. pyvenv без --system-site-packages

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

Очевидный способ решения pyvenvс --system-site-packages:

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

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

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

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

Для Python 3ers

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

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

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

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

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

Нет, нужно больше разрешений, что за? Я думал, что это было странно, но СУДО ПОДАЛИ! Затем он установил пакеты в глобальном расположении.

Урок, который я усвоил, заключался в том, что просто удалите каталог virtualenv. Не двигай его.

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

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

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

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

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

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

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

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

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

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

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

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

Удачи!

Краткий ответ - запустить команду virtualenv с параметром «-no-site-packages».

Длинный ответ с пояснением: -

Итак, бегая туда-сюда и просматривая множество потоков, я обнаружил, что проблема в себе. Вышеупомянутые ответы дали идею, но я хотел бы снова повторить все.

• Проблема в том, что даже если вы активируете среду, она обращается к системной среде из-за того, как мы создали virtualenv.

• когда мы запускаем команду virtualenv env -p python3, она устанавливает virtualenv, но не создает глобальный файл site-packages.txt.

• Из-за этого, когда вы активируете среду командой source activate, там этот файл с именем site.py (имя может быть другим, я просто забыл), который запускается и проверяет, нет ли этого файла, он не добавит ваш путь env к sys.path и использовать системы python.

• чтобы исправить эту проблему, просто запустите virtualenv с дополнительным параметром - no-site-packages, он создаст этот файл, и когда вы активируете среду, он добавит ваш собственный путь к среде в вашу переменную PATH, что сделает его доступным.

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

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

$ source /opt/conda/etc/profile.d/conda.sh # skip if already done 
$ conda activate 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 ...

ОКНА

Для меня решение было не использовать mkvirtualenv, а:

python -m venv path/to/your/virtualenv

workon работает правильно.

while in virtualenv: pip -Vпоказывает путь virtualenv к pip