pip, що встановлюється в глобальних пакетах сайтів замість virtualenv

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

Як бачите, папка глобальних пакетів сайтів містить Markdown, а папка virtualenv - ні.

Примітка: Я раніше встановлював Python2 та Python3 на іншій віртуальній машині (дотримуючись цих інструкцій) і мав ту саму проблему з Python3; Встановлення пакетів у Virtualenv на основі Python2 працювало бездоганно.

Будь-які поради, підказки… будуть дуже вдячні.

Смішно, що ви це вигадали, у мене просто була така сама проблема. Врешті-решт я це вирішив, але досі не впевнений, що це спричинило.

Спробуйте перевірити ваш bin/pipі bin/activateсценарії. В bin/pip, погляд на притон. Це правильно? Якщо ні, виправте. Потім у рядку ~ 42у вашому bin/activate, перевірте, чи правильний ваш шлях до virtualenv. Це буде виглядати приблизно так

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

Якщо це неправильно, виправте це, deactivateтоді . bin/activate, і якщо наша взаємна проблема мала ту саму причину, вона повинна спрацювати. Якщо це все одно не відбувається, ви в будь-якому випадку на правильному шляху. Я пройшов ту саму процедуру вирішення проблем, що і ви, which pipповторюючи , повторюючи, стежачи за стеком тощо.

Переконайтесь у цьому абсолютно

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

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

Якщо нічого з цього не спрацює, тимчасовим рішенням може бути, як сказав Джо Холлоуей,

Просто запустіть pip virtualenv з його повним шляхом (тобто не покладайтесь на пошук виконуваного шляху), і вам навіть не потрібно активувати середовище. Це буде робити правильно.

Можливо, не ідеально, але це мало б спрацювати вкрай мало.

Посилання на моє оригінальне запитання:

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

Для мене це не була проблемою pip чи virtualenv. Це була проблема пітона. Я встановив свій $ PYTHONPATH вручну у ~ / .bash_profile (або ~ / .bashrc) після дотримання деяких підручників в Інтернеті. Цей вручну встановлений $ PYTHONPATH був доступний у virtualenv, оскільки це, мабуть, слід дозволити.

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

Тільки кілька розгалужених доріжок для тих, хто все ще може застрягти! Ура!

У мене була та сама проблема, я її вирішив, видаливши каталог венв і відтворивши його!

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 на моєму Mavericks Mac призвів до того, що пакет 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

Однак це може бути так, що це з якихось причин вирішується у вашій системі pip. Наприклад, ви можете побачити це у вашому virtualenv (це погано):

/ usr / local / bin / pip (або будь-що, що не є на вашому шляху virtualenv).

Щоб вирішити це, перевірте свій pipconfig у:

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

і переконайтеся, що немає нічого, що примушує ваш шлях до Python або ваш шлях до піпа (це мені це виправлено).

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

Я потрапив у ту ж проблему під час встановлення пакета python зсередини virtualenv. Першопричина в моєму випадку була іншою. Зсередини virtualenv я (за звичкою в Ubuntu) робив:

sudo easy_install -Z <package>

Це спричинило ігнорування bin / pip shebang, і він використав кореневий non virtualenv python для встановлення його в глобальних пакунках сайту. Оскільки у нас є віртуальне середовище, нам слід встановити пакет без "sudo"

Я натрапив на ту саму проблему під керуванням Манджаро. Я створив віртуальне середовище за допомогою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 . Довелося вдатися до налагодження pip, щоб простежити поганий шлях.

Як виявляється, у моєму каталозі профілю був файл конфігурації 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

Видалення псевдонімів та відтворення віртуального env за допомогою 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
>>> 

Примітки:

Чому не судо?

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

Якщо ви перейменуєте папку свого проекту (як зазначено у прийнятій відповіді) ...

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

Наприклад:

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, розташований у вашомуVirtualEnvName \ Scripts

Він повинен встановити пакет всередині Lib \ site-пакети у вашому віртуальному середовищі

У мене теж була ця проблема. Виклик sudo pip installпризвів до того, що пакети Python були встановлені в глобальній директорії пакетів сайтів, і дзвінки pip installпросто працювали нормально. Тож не використовуйте sudo у virtualenv.

Та сама проблема. Python3.5 та pip 8.0.2 встановлені з Linuxrpm .

Я не знайшов основної причини і не можу дати належної відповіді. Схоже, існує безліч можливих причин.

Однак я сподіваюся, що можу допомогти поділитися своїми спостереженнями та обійти шляхи.

1. pyvenv з --system-site-packages

   • ./binне містить pip,pip доступний із системних пакетів веб-сайтів
   • пакети встановлюються глобально ( ПОМИЛКА? )

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

   • pipвстановлюється в ./bin, але це інша версія (відensurepip )
   • пакети встановлюються у віртуальному середовищі ( OK )

Очевидний спосіб вирішення 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. Пивенв знову працює.

Це трапилося зі мною, коли я створив 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. Не рухайте його.

Виникла ця проблема після встановлення 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 з якихось причин. Це спричиняє інсталяцію пакетів у глобальних пакетів сайтів. Розміщуючи це тут для тих, хто може зіткнутися з цією проблемою в майбутньому.

У мене була саме проблема із заголовка, і я її вирішив. Pip почав встановлюватися у веб-пакетах venv після того, як я очистив PATH: він мав шлях до мого локального каталогу ~ / bin на самому початку.

Отже, моя порада: ретельно перевірте змінні середовища на наявність «сміття» чи будь-яких нестандартних речей. На жаль, virtualenv може бути чутливим до них.

Удачі!

Короткою відповіддю запускається Command virtualenv з параметром “—no-site-пакети”.

Довга відповідь із поясненням: -

Тож, пробігшись туди-сюди та пройшовши безліч потоків, я виявив проблему. Наведені вище відповіді дали ідею, але я хотів би ще раз переглянути все.

• Проблема полягає навіть у тому, що ви активуєте середовище, яке воно стосується системного середовища через те, як ми створили virtualenv.

• коли ми запускаємо команду virtualenv env -p python3, вона встановить virtualenv, але не створить no-global — site-пакети.txt.

• Через це, коли ви активуєте середовище за допомогою команди джерела активації, цей файл називається site.py (ім'я може бути різним, я просто забув), який запускається та перевіряє, чи немає цього файлу, він не додасть ваш шлях env до sys.path і використовувати системи python.

• щоб виправити цю проблему, просто запустіть virtualenv з додатковим параметром - no-site-пакети, він створить цей файл, і коли ви активуєте середовище, він додасть ваш власний шлях середовища до вашої змінної 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 працює коректно.

в той час як у virtualenv: pip -Vпоказує шлях virtualenv до pip