pip installer dans des paquets de site globaux au lieu de virtualenv
L'utilisation de pip pour installer un package dans virtualenv entraîne son installation 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 sous Homebrew:
Ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)"
brew install python3 --with-brewed-openssl
Modification de la variable $PATH dans .bash_profile; ajouté la ligne suivante:
export PATH=/usr/local/bin:$PATH
L'exécution de which python3 renvoie /usr/local/bin/python3 (après le redémarrage du shell).
_ {Remarque: which python3 renvoie toujours/usr/bin/python si.} _
Virtualenv installé à l'aide de pip3:
pip3 install virtualenv
Ensuite, créez un nouveau virtualenv et activez-le:
virtualenv testpy3 -p python3
cd testpy3
source bin/activate
Remarque: si je ne spécifie pas -p python3, il manquera pip dans le dossier bin de virtualenv.
L'exécution de which pip et which pip3 renvoie le dossier virtualenv:
/Users/kristof/VirtualEnvs/testpy3/bin/pip3
Maintenant, quand j'essaye d'installer, par exemple Markdown utilisant pip dans le virtualenv activé, pip s’installe dans le dossier global site-packages au lieu du dossier site-packages du virtualenv.
pip install markdown
L'exécution de pip list renvoie:
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 constater, le dossier global site-packages contient Markdown, contrairement au dossier virtualenv.
Remarque: j'avais déjà installé Python2 et Python3 sur un VM différent (suivi this instructions) et le même problème avec Python3; L'installation de paquets dans un virtualenv basé sur Python2 a parfaitement fonctionné.
Tous les conseils, astuces,… seraient très appréciés.
C'est marrant que tu en aies parlé, je viens d'avoir exactement le même problème. Je l'ai finalement résolu, mais je ne suis toujours pas sûr de la cause.
Essayez de vérifier vos scripts bin/pip et bin/activate. Dans bin/pip, regardez le Shebang. Est-ce correct? Si non, corrigez-le. Puis, sur la ligne ~ 42 de votre bin/activate, vérifiez si votre chemin virtualenv est correct. Ça va ressembler à quelque chose comme ça
VIRTUAL_ENV="/Users/me/path/to/virtual/environment"
Si c'est faux, corrigez-le, deactivate, puis . 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. J'ai suivi la même procédure de résolution de problèmes que vous, which pip, répétée, en suivant la trace de la pile, etc.
Assurez-vous absolument que
/Users/kristof/VirtualEnvs/testpy3/bin/pip3
est ce que vous voulez, et ne faites pas référence à un autre projet de test portant le même nom (j’ai eu ce problème et je ne sais pas du tout comment cela a commencé. Mon soupçon est d’exécuter plusieurs virtualenvs en même temps).
Si rien de tout cela ne fonctionne, une solution temporaire pourrait être, comme l'a dit Joe Holloway,
Il suffit d’exécuter le pip de virtualenv avec son chemin complet (c’est-à-dire qu’il ne faut pas chercher dans le chemin des fichiers exécutables) et qu’il n’est même pas nécessaire d’activer l’environnement. Cela fera le bon choix.
Peut-être pas idéal, mais cela devrait marcher à la rigueur.
Lien vers ma question initiale:
Pour moi, ce n'était pas un problème de pépin ou de virtualenv. C'était un problème de python. J'avais défini manuellement $ PYTHONPATH dans ~/.bash_profile (ou ~/.bashrc) après avoir suivi un tutoriel en ligne. $ PYTHONPATH, défini manuellement, était disponible dans virtualenv car il devrait probablement être autorisé.
De plus, add2virtualenv n'ajoutait pas mon chemin de projet à mon $ PYTHONPATH pour une raison quelconque dans virtualenv.
Quelques chemins bifurqués 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 de pip install <package_name> à partir du répertoire /bin au sein 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 de site global Python 2.7. Ceci en dépit du fait que mon $ PATH a commencé avec le répertoire contenant pip. Bizarre. Cela n'arrive pas sur CentOS. Pour moi, la solution consistait à appeler pip3 au lieu de pip. Lorsque j'avais installé pip dans l'environnement virtuel via ez_setup , trois exécutables "pip" avaient été installés dans le répertoire /bin - pip, pip3 et pip3.3. Curieusement, les trois fichiers étaient exactement les mêmes. L'appel de pip3 install <package_name> a provoqué l'installation correcte du package Python dans le répertoire site-packages local. L'appel de pip avec le chemin complet dans l'environnement virtuel a également fonctionné correctement. Je serais intéressé de savoir pourquoi mon Mac n'utilise pas $ PATH comme je le pensais.
J'ai rencontré le même problème lors de l'installation d'un paquet Python à partir d'un fichier virtualenv . La cause fondamentale de mon cas était différente . À partir de virtualenv, j'étais (par habitude sous Ubuntu), à savoir:
Sudo easy_install -Z <package>
Cela a pour conséquence que le bin/pip Shebang est ignoré et qu'il utilise 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".
J'ai eu un problème similaire après la mise à jour à pip==8.0.0. Nous avons dû recourir au pip de débogage pour tracer le mauvais chemin.
Comme il se trouve que mon répertoire de profil contenait un fichier de configuration distutils avec des valeurs de chemin vides. Cela entraînait 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é là ou comment il a eu des valeurs vides, mais il a commencé après la mise à jour de pip.
Au cas où quelqu'un d'autre tomberait sur le même problème, la suppression du fichier ~/.pydistutils.cfg (ou la suppression du chemin de configuration vide) corrigeait le problème dans mon environnement, car pip revenait à la configuration distribuée par défaut.
La première chose à vérifier est quel emplacement d'emplacement pip est résolu à:
which pip
si vous êtes dans un environnement virtuel, vous vous attendriez à ce que cela vous donne quelque chose comme:
/path/to/virtualenv/.name_of_virtualenv/bin/pip
Cependant, il est possible que cela se résolve pour 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 ne se trouve pas dans votre chemin virtuel).
Pour résoudre ce problème, vérifiez votre pipconfig dans:
~/.pipconf
~/.conf/pip
/etc/pip.conf
et assurez-vous que rien ne force votre chemin Python ou votre chemin pip (cela le corrige pour moi).
Ensuite, essayez de démarrer un nouveau terminal et reconstruisez votre virtualenv (supprimez-le puis recréez-le)
Après avoir créé un environnement virtuel, essayez d’utiliser pip situé dans votreVirtualEnvName\Scripts
Il devrait installer un paquet dans Lib\site-packages dans votre environnement virtuel
Aucune des solutions ci-dessus n'a fonctionné pour moi.
Mon venv était actif. pip -V et which pip m’ont donné le bon chemin virtuel, mais lorsque je pip install- paquets avec activé venv, mon pip freeze est resté vide.
Toutes les variables d'environnement étaient également correctes.
Enfin, je viens de changer pip et de retirer virtualenv:
easy_install pip==7.0.2
pip install pip==10
Sudo pip uninstall virtualenv
Réinstallez 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.
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 commande pip a fonctionné comme prévu.
Je ne pense pas avoir utilisé Sudo lors de la première création de virtualenv et c’est peut-être la raison pour laquelle je n’ai pas accès à pip à partir de virtualenv. J’ai pu accéder à pip2 avant ce correctif, ce qui était étrange.
Voici quelques pratiques qui pourraient vous éviter des maux de tête lors de l’utilisation de Virtual Environments:
- Créez un dossier pour vos projets.
- Créez votre Virtualenv projects 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, toujours " désactivez " votre environnement.
- Évitez de renommer votre dossier de projet.
Pour une meilleure représentation de ces pratiques, voici une simulation:
créer 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 d'activation
$ source google_drive/bin/activate
installer des paquets
(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...
paquet 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
$
forfait 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 nouvel environnement pour vous, définissant $ PATH et quelques autres variables et paramètres. Lorsque vous utilisez le paquet d'installation Sudo pip , vous exécutez Virtualenv en tant que root , en évitant tout l'environnement créé, puis en installant le paquet sur des packages site global, et non dans le projet folder où vous avez un environnement virtuel, bien que vous ayez activé l'environnement.
Si vous renommez le dossier de votre projet (comme indiqué 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)
Ce problème se produit lorsque vous créez une instance virtualenv, puis modifiez le nom du dossier parent.
J'ai eu ce problème. Il s’est avéré qu’un espace dans l’un de mes noms de dossier était à l’origine du problème. J'ai supprimé l'espace, supprimé et rétabli à l'aide de venv, et tout allait bien.
Beaucoup de bonnes discussions ci-dessus, mais des exemples virtuels ont été utilisés. Comme 'conda' est maintenant l'outil recommandé pour gérer virtualenv, j'ai résumé les étapes de l'exécution de pip in conda env comme suit.
Je vais utiliser py36r comme nom de env, et/opt/conda/envs est le préfixe des envs):
$ source /opt/conda/etc/profile.d/conda.sh # ignorer si déjà fait
$ conda activate py36r
$ pip installer pkg_xyz
$ pip liste | grep pkg_xyz
Notez que le pip exécuté doit être dans/opt/conda/envs/py36r/bin/pip (pas/opt/conda/bin/pip).
Alternativement, vous pouvez simplement exécuter le programme suivant sans activer
$/opt/conda/envs/py36r/bin/pip
De plus, si vous installez avec conda, vous pouvez installer sans activer:
$ conda install -n py36r pkg_abc ...
Cela m'est arrivé lorsque j'ai installé virtualenv avec --python=python3.6, mais que j'ai ensuite essayé d'utiliser pip2 install.
Créer virtualenv avec l'indicateur de la version que vous utiliserez résout les problèmes d'autorisation. Pour vérifier, essayez which pip ou which pip2 ou which pip3 (selon votre choix). Si tout pip que vous utilisez montre le chemin non venv, voici votre problème.
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 cela ici pour tous ceux qui pourraient être confrontés à ce problème à l'avenir.
J'ai eu ce problème également. L'appel de Sudo pip install a provoqué l'installation des paquets Python dans le répertoire global site-packages et l'appel de pip install a bien fonctionné . Donc, pas d'utilisation Sudo dans virtualenv.
Avait ce problème après l'installation de Divio: il avait changé mon chemin ou mon environnement d'une manière ou d'une autre, en lançant un terminal.
La solution dans ce cas était simplement de faire source ~/.bash_profile qui devrait déjà être configuré pour vous ramener à votre état original pyenv/pyenv-virtualenv.
J'ai eu exactement le problème du titre, et je l'ai résolu. Pip a commencé à s’installer dans les paquets-site de venv après avoir nettoyé mon chemin: il y avait un chemin vers mon répertoire local ~/bin au tout début.
Donc, mon conseil: vérifiez soigneusement les variables de votre environnement pour rechercher des "déchets" ou des éléments non standard. Malheureusement, virtualenv peut être sensible à ceux-ci.
Bonne chance!
J'ai eu ce problème, et après avoir essayé toutes les solutions ci-dessus, j'ai tout enlevé et j'ai recommencé.
Dans mon cas, j’ai utilisé Sudo pour créer l’un des dossiers dans lequel l’environnement virtuel existait et Sudo a accordé les privilèges à root.
J'étais très énervé! Mais ça a marché!
En quelque sorte, un fichier setup.cfg avec un préfixe = "" dans le dossier du projet
l’exécution de l’installation de pip sur virtualenv en dehors du dossier de projet a fonctionné de sorte qu’elle indique à pip d’utiliser un préfixe vide dont le caractère est "/"
supprimer le fichier corrigé
Accédez au répertoire bin de votre environnement virtuel et écrivez comme ceci:
./pip3 install <package-name>
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 ceci est de mettre à jour votre version de Python Minor/Patch si possible. J'ai remarqué que je courais 3.5.1 et mis à jour à 3.5.2. Pyvenv fonctionne à nouveau.
Cela m'est arrivé lorsque j'ai créé virtualenv au mauvais endroit. J'ai alors pensé que je pourrais déplacer le répertoire à un autre endroit sans que cela importe. C'était important.
mkdir ~/projects
virtualenv myenv
cd myenv
git clone [my repository]
Oh merde, j'ai oublié de cd dans projects avant de créer virtualenv et de cloner le représentant. Oh bien, je suis trop paresseux pour détruire et recréer. Je vais juste déplacer le répertoire sans problèmes.
cd ~
mv myenv projects
cd projects/myenv/myrepo
pip install -r requirements
Non, veut plus d'autorisations, qu'est-ce que? ?__. Je pensais que c'était étrange mais Sudo AWAY! Il a ensuite installé les packages dans un emplacement global.
La leçon que j'ai apprise est qu'il suffit de supprimer le répertoire virtualenv. Ne le déplace pas.
Le même problème. Python3.5 et pip 8.0.2 installés à partir de Linux rpm 's.
Je n'ai pas trouvé de cause principale et je ne peux pas donner une réponse correcte. Il semble y avoir plusieurs causes possibles.
Cependant, j'espère pouvoir partager mon observation et une solution de contournement.
pyvenvavec--system-site-packages./binne contient paspip,pipest disponible à partir des packages de site système- les packages sont installés globalement ( BUG? )
pyvenvsans--system-site-packagespipest installé dans./bin, mais c'est une version différente (à partir deensurepip)- les packages sont installés dans l'environnement virtuel (OK)
Solution évidente pour pyvenv avec --system-site-packages:
- le créer sans l'option
--system-site-packages - remplacez
include-system-site-packages = falsepartruedans le fichierpyvenv.cfg
Il est également intéressant de vérifier que vous n'avez pas modifié le chemin d'accès à votre virtualenv.
Dans ce cas, la première ligne dans bin/pip (et le reste des exécutables) aurait un chemin incorrect.
Vous pouvez soit éditer ces fichiers et corriger le chemin, soit supprimer et réinstaller virtualenv.