pip installation dans des packages de sites globaux au lieu de virtualenv

L'utilisation de pip3pour installer un package dans a virtualenventraîne l' installation du package dans le dossier global site-packages au lieu de celui du dossier virtualenv. Voici comment j'ai configuré Python3 et virtualenv sur OS X Mavericks (10.9.1):

J'ai installé Python3 en utilisant Homebrew:

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

Changement de la $PATHvariable dans .bash_profile; a ajouté la ligne suivante:

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

L'exécution which python3revient /usr/local/bin/python3(après le redémarrage du shell).

Remarque: which python3renvoie toujours / usr/bin/pythoncependant.

Installé en virtualenvutilisant pip3:

pip3 install virtualenv

Ensuite, créez un nouveau virtualenvet activez-le:

virtualenv testpy3 -p python3
cd testpy3
source bin/activate

Remarque: si je ne spécifie pas -p python3, pip sera absent du dossier bin de virtualenv.

L'exécution which pipet les which pip3deux renvoient le dossier virtualenv:

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

Maintenant, quand j'essaye d'installer par exemple Markdown en utilisant pip dans le virtualenv activé, pip installera dans le dossier global site-packages au lieu du dossier site-packages du virtualenv.

pip install markdown

pip listRetours courants :

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

Contenu de /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/

Contenu de /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/

Comme vous pouvez le voir, le dossier global site-packages contient Markdown, pas le dossier virtualenv.

Remarque: j'ai déjà installé Python2 et Python3 sur une machine virtuelle différente (j'ai suivi ces instructions) et j'ai eu le même problème avec Python3; l'installation de packages dans un virtualenv basé sur Python2 fonctionnait parfaitement.

Tous les conseils, astuces,… seraient très appréciés.

C'est drôle que vous ayez évoqué cela, j'ai juste eu exactement le même problème. Je l'ai finalement résolu, mais je ne sais toujours pas ce qui l'a causé.

Essayez de vérifier vos scripts bin/pipet bin/activate. Dans bin/pip, regardez le shebang. Est-ce correct? Sinon, corrigez-le. Ensuite, en ligne ~ 42dans votre bin/activate, vérifiez si votre chemin virtualenv est correct. Ça ressemblera à quelque chose comme ça

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

Si c'est faux, corrigez-le deactivate, alors . bin/activate, et si notre problème mutuel avait la même cause, cela devrait fonctionner. Si ce n'est toujours pas le cas, vous êtes sur la bonne voie, de toute façon. J'ai suivi la même routine de résolution de problèmes que vous, which pipen continuant de suivre la trace de la pile, etc.

Assurez-vous absolument que

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

est ce que vous voulez, et ne faisant pas référence à un autre projet de test portant le même nom (j'ai eu ce problème, et je n'ai aucune idée de comment cela a commencé. Je soupçonne d'exécuter plusieurs virtualenvs en même temps).

Si rien de tout cela ne fonctionne, une solution temporaire peut être, comme l'a dit Joe Holloway,

Exécutez simplement le pip de virtualenv avec son chemin complet (c'est-à-dire ne comptez pas sur la recherche du chemin de l'exécutable) et vous n'avez même pas besoin d'activer l'environnement. Cela fera la bonne chose.

Peut-être pas idéal, mais cela devrait fonctionner à la rigueur.

Lien vers ma question initiale:

VirtualEnv / Pip essayant d'installer des packages globalement

Pour moi, ce n'était pas un problème de pip ou de virtualenv. C'était un problème de python. J'avais défini mon $ PYTHONPATH manuellement dans ~ / .bash_profile (ou ~ / .bashrc) après avoir suivi un tutoriel en ligne. Cet ensemble manuel $ PYTHONPATH était disponible dans virtualenv car il devrait probablement être autorisé.

De add2virtualenvplus, je n'ajoutais pas le chemin de mon projet à mon $ PYTHONPATH pour une raison quelconque dans virtualenv.

Juste quelques chemins de bifurcation pour ceux qui pourraient encore être bloqués! À votre santé!

J'ai eu le même problème, je l'ai résolu en supprimant le répertoire venv et en le recréant!

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

Maintenant, tout fonctionne comme un charme.

J'ai eu ce problème également. L'appel à pip install <package_name>partir du /binrépertoire de mon environnement virtuel Python 3.3 sur mon Mac Mavericks a entraîné l'installation du package Python dans le répertoire des packages du site global Python 2.7. C'était malgré le fait que mon $ PATH a commencé avec le répertoire contenant pip. Bizarre. Cela ne se produit pas sur CentOS. Pour moi, la solution appelait pip3au lieu de pip. Quand j'avais installé pip dans l'environnement virtuel via ez_setup , trois exécutables "pip" avaient été installés dans le /binrépertoire - pip, dans le répertoirepip3 et pip3.3. Curieusement, les trois fichiers étaient exactement les mêmes. Appelpip3 install <package_name>a provoqué l'installation correcte du package Python dans le répertoire local site-packages. L'appel pipavec le chemin complet vers l'environnement virtuel fonctionnait également correctement. Je serais intéressé de savoir pourquoi mon Mac n'utilise pas $ PATH comme je l'attendais.

La première chose à vérifier est de savoir à quel emplacement pip résout:

which pip

si vous êtes dans une virtualenv, vous vous attendez à ce que cela vous donne quelque chose comme:

/chemin/to/virtualenv/.name_of_virtualenv/bin/pip

Cependant, il se peut qu'il soit résolu par votre système pip pour une raison quelconque. Par exemple, vous pouvez voir ceci depuis votre virtualenv (c'est mauvais):

/ usr / local / bin / pip (ou tout ce qui n'est pas dans votre chemin virtualenv).

Pour résoudre ce problème, vérifiez votre pipconfig dans:

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

et assurez-vous que rien ne contraint votre chemin Python ou votre chemin pip (cela a résolu le problème pour moi).

Ensuite, essayez de démarrer un nouveau terminal et reconstruisez votre virtualenv (supprimez-le puis créez-le à nouveau)

J'ai rencontré le même problème lors de l'installation d'un package python à partir d'un virtualenv. La cause fondamentale dans mon cas était différente. Depuis le virtualenv, je faisais (par habitude sur Ubuntu):

sudo easy_install -Z <package>

Cela a fait ignorer le bin / pip shebang et a utilisé le python non virtualenv de la racine pour l'installer dans les packages de site globaux. Puisque nous avons un environnement virtuel, nous devrions installer le paquet sans "sudo"

Je suis tombé sur le même problème en exécutant Manjaro. J'ai créé l'environnement virtuel en utilisant python3 -m ven venvpuis activé en utilisant source venv/bin/actiave. which pythonet les which pipdeux pointaient vers les binaires corrects dans le virtualenv, mais je n'ai pas pu installer sur le virtualenv, même en utilisant le chemin complet des binaires. Il s'est avéré que lorsque j'ai désinstallé le package python-pip avec sudo pacman -R python-pip python-reportlab(je devais inclure reportlab pour satisfaire les dépendances), tout a commencé à fonctionner comme prévu. Je ne sais pas pourquoi, mais cela est probablement dû à une double installation où le paquet système prend la priorité.

J'ai eu un problème similaire après la mise à jour vers pip==8.0.0. J'ai dû recourir au débogage de pip pour tracer le mauvais chemin.

En fait, mon répertoire de profil contenait un fichier de configuration distutils avec des valeurs de chemin vides. Cela provoquait l'installation de tous les packages dans le même répertoire racine au lieu de l'environnement virtuel approprié (dans mon cas /lib/site-packages).

Je ne sais pas comment le fichier de configuration est arrivé ou comment il avait des valeurs vides, mais il a commencé après la mise à jour de pip.

Au cas où quelqu'un d'autre tomberait sur ce même problème, la simple suppression du fichier ~/.pydistutils.cfg(ou la suppression du chemin de configuration vide) a résolu le problème dans mon environnement car pip est revenu à la configuration distribuée par défaut.

Accédez au répertoire bin de votre environnement virtuel et écrivez comme ceci:

./pip3 install <package-name>

J'ai eu le même problème sur macos avec python 2 et 3 installés.

De plus, j'avais des alias pour pointer vers python3 et pip3 dans mon fichier .bash_profile.

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

La suppression des alias et la recréation d'environnement virtuel à l'aide de la python3 -m venv venvrésolution du problème.

Je suis tombé sur le même problème aujourd'hui. J'ai simplement réinstallé pip globalement avec sudo easy_install pip(OSX / Max), puis créé à nouveau mon virtualenv avec sudo virtualenv nameOfVEnv. Ensuite, après avoir activé le nouveau virtualenv, la pipcommande a fonctionné comme prévu.

Je ne pense pas avoir utilisé sudolors de la première création de virtualenv et c'est peut-être la raison pour laquelle je n'ai pas accès à pippartir de virtualenv, j'ai pu y accéder pip2avant ce correctif, ce qui était étrange.

Voici quelques pratiques qui pourraient éviter les maux de tête lors de l'utilisation d' environnements virtuels:

• Créez un dossier pour vos projets.
• Créez vos projets Virtualenv dans ce dossier.
• Après avoir activé l'environnement de votre projet, n'utilisez jamais " sudo pip install package ".
• Après avoir terminé votre travail, " désactivez " toujours votre environnement.
• Évitez de renommer votre dossier de projet.

Pour une meilleure représentation de ces pratiques, voici une simulation:

création d'un dossier pour vos projets / environnements

$ mkdir venv

créer un environnement

$ cd venv/ 

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

environnement activant

$ source google_drive/bin/activate

installation de packages

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

package disponible dans l'environnement

(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()
>>>

désactiver l'environnement

(google_drive) $ deactivate 

$ 

package NON DISPONIBLE en dehors de l'environnement

(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
>>> 

Remarques:

Pourquoi pas sudo?

Virtualenv crée un tout nouvel environnement pour vous, définissant $ PATH et quelques autres variables et paramètres. Lorsque vous utilisez le package d'installation sudo pip , vous exécutez Virtualenv en tant que root , en échappant à tout l'environnement qui a été créé, puis en installant le package sur des packages de site globaux, et non dans le dossier de projet où vous avez un environnement virtuel, bien que vous ont activé l'environnement.

Si vous renommez le dossier de votre projet (comme mentionné dans la réponse acceptée) ...

... vous devrez ajuster certaines variables de certains fichiers dans le répertoire bin de votre projet.

Par exemple:

bin / pip, ligne 1 (She Bang)

bin / activate, ligne 42 (VIRTUAL_ENV)

J'ai eu ce problème. Il s'est avéré qu'il y avait un espace dans l'un de mes noms de dossier qui a causé le problème. J'ai supprimé l'espace, supprimé et rétabli à l'aide de venv, et tout allait bien.

Ce problème se produit lorsque vous créez une instance virtualenv, puis modifiez le nom du dossier parent.

Aucune des solutions ci-dessus n'a fonctionné pour moi.

Mon venv était actif. pip -Vet which pipm'a donné le bon chemin virtualenv, mais quand j'ai pip install-ed paquets avec venv activé, mon est pip freezeresté vide.

Toutes les variables d'environnement étaient également correctes.

Enfin, je viens de changer pip et de supprimer virtualenv:

easy_install pip==7.0.2

pip install pip==10

sudo pip uninstall virtualenv

Réinstaller venv:

sudo pip install virtualenv

Créer venv:

python -m virtualenv venv_name_here

Et tous les paquets installés correctement dans mon venv à nouveau.

Après avoir créé l'environnement virtuel, essayez d'utiliser pip situé dans yourVirtualEnvName \ Scripts

Il devrait installer un package dans Lib \ site-packages dans votre environnement virtuel

J'ai eu ce problème également. L'appel a sudo pip installentraîné l'installation des packages Python dans le répertoire global site-packages et l'appel pip installa bien fonctionné. Donc, n'utilisez pas sudo dans virtualenv.

Le même problème. Python3.5 et pip 8.0.2 installés à partir de Linuxrpm .

Je n'ai pas trouvé de cause principale et je ne peux pas donner de réponse correcte. Il semble qu'il existe plusieurs causes possibles.

Cependant, j'espère pouvoir vous aider en partageant mon observation et une solution de contournement.

1. pyvenv avec --system-site-packages

   • ./binne contient pas pip, pipest disponible à partir des packages de site système
   • les paquets sont installés globalement ( BUG? )

2. pyvenv sans pour autant --system-site-packages

   • pipest installé dans ./bin, mais c'est une version différente (de ensurepip)
   • les packages sont installés dans l'environnement virtuel ( OK )

Solution de contournement évidente pour pyvenvavec --system-site-packages:

• créez-le sans l' --system-site-packagesoption
• changer include-system-site-packages = falsepour trueen pyvenv.cfgfichier

Cela vaut également la peine de vérifier que vous n'avez pas modifié en quelque sorte le chemin de votre virtualenv.

Dans ce cas, la première ligne de bin/pip(et le reste des exécutables) aurait un chemin incorrect.

Vous pouvez soit modifier ces fichiers et corriger le chemin, soit supprimer et réinstaller le virtualenv.

Pour Python 3ers

Essayez de mettre à jour. J'ai eu exactement le même problème et j'ai essayé la réponse de Chases, mais sans succès. Le moyen le plus rapide de refactoriser cela est de mettre à jour votre version Python Minor / Patch si possible. J'ai remarqué que j'utilisais 3.5.1 et mis à jour vers 3.5.2. Pyvenv fonctionne à nouveau.

Cela m'est arrivé lorsque j'ai créé le virtualenv au mauvais emplacement. J'ai alors pensé que je pouvais déplacer le répertoire vers un autre emplacement sans que cela n'ait d'importance. Cela comptait.

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

Oh merde, j'ai oublié de cd dedans projectsavant de créer le virtualenv et de cloner le représentant. Eh bien, je suis trop paresseux pour détruire et recréer. Je vais simplement déplacer le répertoire sans problème.

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

Non, veut plus d'autorisations, qu'est-ce que c'est? J'ai trouvé ça étrange mais SUDO AWAY! Il a ensuite installé les packages dans un emplacement global.

La leçon que j'ai apprise était, supprimez simplement le répertoire virtualenv. Ne bougez pas.

J'ai eu ce problème après l'installation de Divio: cela avait changé mon PATH ou mon environnement d'une manière ou d'une autre, car il lance un terminal.

La solution dans ce cas était simplement de faire source ~/.bash_profilece qui devrait déjà être configuré pour vous ramener à votre état pyenv / pyenv-virtualenv d'origine.

Cela m'est arrivé lorsque j'ai installé virtualenv avec --python=python3.6indicateur, mais que j'ai ensuite essayé de l'utiliser pip2 install.
La création de virtualenv avec l'indicateur de la version que vous utiliserez résout les problèmes d'autorisation. Pour vérifier, essayez which pipou which pip2ou which pip3(dépend de votre choix). Si l'un de ceux que pipvous utilisez montre un chemin non vers venvici, c'est votre problème.

D'une manière ou d'une autre, un fichier setup.cfg avec un préfixe = "" dans le dossier du projet

exécuter pip install sur le virtualenv en dehors du dossier du projet fonctionnait donc de l'intérieur, il disait à pip d'utiliser un préfixe vide qui par défaut était "/"

la suppression du fichier l'a corrigé

J'ai eu ce problème, et après avoir essayé toutes les solutions ci-dessus, je viens de tout supprimer et j'ai recommencé.

Dans mon cas, j'ai utilisé sudo pour créer l'un des dossiers dans lesquels l'environnement virtuel existait, et sudo donne les privilèges à root

J'étais très énervé! Mais ça a marché!

Je dois utiliser «sudo» pour installer des paquets via pip sur mon système ubuntu pour une raison quelconque. Cela provoque l'installation des packages dans des packages de site globaux. Mettre ceci ici pour quiconque pourrait être confronté à ce problème à l'avenir.

J'avais exactement le problème du titre et je l'ai résolu. Pip a commencé à s'installer dans les packages du site venv après avoir nettoyé mon PATH: il avait un chemin vers mon répertoire local ~ / bin au tout début.

Donc, mon conseil: vérifiez soigneusement vos variables d'environnement pour les «déchets» ou tout autre élément non standard. Malheureusement, virtualenv peut y être sensible.

Bonne chance!

La réponse courte est d'exécuter la commande virtualenv avec le paramètre «—no-site-packages».

Réponse longue avec explication: -

Donc, après avoir couru ici et là, et passé par beaucoup de threads, j'ai trouvé le problème. Les réponses ci-dessus ont donné l'idée, mais je voudrais tout de même revenir sur tout.

• Le problème est que même si vous activez l'environnement, il fait référence à l'environnement système en raison de la façon dont nous avons créé le virtualenv.

• lorsque nous exécutons la commande virtualenv env -p python3, il installera le virtualenv mais il ne créera pas de no-global-site-packages.txt.

• Pour cette raison, lorsque vous activez l'environnement par la commande d'activation de la source, ce fichier appelé site.py (le nom peut être différent, j'ai juste oublié) qui s'exécute et vérifie si ce fichier n'est pas présent, il n'ajoutera pas votre chemin d'environnement à sys.path et utilisez les systèmes python.

• pour résoudre ce problème, lancez simplement virtualenv avec un paramètre supplémentaire —no-site-packages, il créera ce fichier et lorsque vous activerez l'environnement, il ajoutera votre chemin d'environnement personnalisé dans votre variable PATH le rendant accessible.

Beaucoup de bonnes discussions ci-dessus, mais des exemples virtualenv ont été utilisés. Puisque 'conda' est maintenant l'outil recommandé pour gérer virtualenv, j'ai résumé les étapes de l'exécution de pip dans conda env comme suit.

J'utiliserai py36r comme nom de l'environnement, et / opt / conda / envs est le préfixe des 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

Notez que le pip exécuté doit être in /opt/conda/envs/py36r/bin/pip(not /opt/conda/bin/pip).

Alternativement, vous pouvez simplement exécuter ce qui suit sans activer conda

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

De plus, si vous installez en utilisant conda, vous pouvez installer sans activer:

$ conda install -n py36r pkg_abc ...

LES FENÊTRES

Pour moi, la solution n'était pas d'utiliser mkvirtualenv, mais:

python -m venv path/to/your/virtualenv

workon fonctionne correctement.

while in virtualenv: pip -Vmontre le chemin de virtualenv vers pip