virtualenv --no-site-packages et pip trouvent toujours des packages globaux?

J'avais l'impression que virtualenv --no-site-packagescela créerait un environnement Python complètement séparé et isolé, mais cela ne semble pas.

Par exemple, j'ai python-django installé globalement, mais je souhaite créer un virtualenv avec une version différente de Django.

$ virtualenv --no-site-packages foo       
New python executable in foo/bin/python
Installing setuptools............done.
$ pip -E foo install Django
Requirement already satisfied: Django in /usr/share/pyshared
Installing collected packages: Django
Successfully installed Django

D'après ce que je peux dire, ce qui pip -E foo installprécède est censé réinstaller une nouvelle version de Django. De plus, si je dis à pip de geler l'environnement, j'obtiens beaucoup de paquets. Je m'attendrais à ce que pour un nouvel environnement avec --no-site-packagesce serait vide?

$ pip -E foo freeze
4Suite-XML==1.0.2
BeautifulSoup==3.1.0.1
Brlapi==0.5.3
BzrTools==1.17.0
Django==1.1
... and so on ...

Suis-je mal compris comment --no-site-packagesest censé fonctionner?

J'ai eu un problème comme celui-ci, jusqu'à ce que je réalise que (bien avant que je découvre virtualenv), j'étais allé ajouter des répertoires au PYTHONPATH dans mon fichier .bashrc. Comme cela faisait plus d'un an auparavant, je n'y ai pas pensé tout de suite.

Vous devez vous assurer que vous exécutez le pipbinaire dans l'environnement virtuel que vous avez créé, et non dans l'environnement global.

env/bin/pip freeze

Voir un test:

Nous créons le virtualenv avec l' --no-site-packagesoption:

$ virtualenv --no-site-packages -p /usr/local/bin/python mytest
Running virtualenv with interpreter /usr/local/bin/python
New python executable in mytest/bin/python
Installing setuptools, pip, wheel...done.

Nous vérifions la sortie de freezela nouvellement créée pip:

$ mytest/bin/pip freeze
argparse==1.3.0
wheel==0.24.0

Mais si nous utilisons le global pip, voici ce que nous obtenons:

$ pip freeze
...
pyxdg==0.25
...
range==1.0.0
...
virtualenv==13.1.2

Autrement dit, tous les packages pipinstallés dans tout le système. En vérifiant, which pipnous obtenons (du moins dans mon cas) quelque chose comme /usr/local/bin/pip, ce qui signifie que lorsque nous le faisons, nous pip freezeappelons ce binaire au lieu de mytest/bin/pip.

Finalement, j'ai trouvé que, pour une raison quelconque, pip -E ne fonctionnait pas. Cependant, si j'active réellement virtualenv et que j'utilise easy_install fourni par virtualenv pour installer pip, puis que j'utilise pip directement de l'intérieur, cela semble fonctionner comme prévu et n'afficher que les packages dans virtualenv

Je sais que c'est une question très ancienne mais pour ceux qui arrivent ici à la recherche d'une solution:

N'oubliez pas d' activer virtualenv ( source bin/activate) avant de démarrer pip freeze. Sinon, vous obtiendrez une liste de tous les packages globaux.

Effacez temporairement le PYTHONPATHavec:

export PYTHONPATH=

Ensuite, créez et activez l'environnement virtuel:

virtualenv foo
. foo/bin/activate

Seulement à ce moment-là:

pip freeze

--no-site-packagesdevrait, comme son nom l'indique, supprimer le répertoire standard site-packages de sys.path. Tout ce qui se trouve dans le chemin Python standard y restera.

Un problème similaire peut se produire sous Windows si vous appelez directement des scripts script.pyqui utilisent ensuite l'ouvreur par défaut de Windows et ouvre Python en dehors de l'environnement virtuel. L'appeler avec python script.pyutilisera Python avec l'environnement virtuel.

Cela semble également se produire lorsque vous déplacez le répertoire virtualenv vers un autre répertoire (sous Linux) ou que vous renommez un répertoire parent.

J'avais ce même problème. Le problème pour moi (sur Ubuntu) était que mon nom de chemin contenait $. Lorsque j'ai créé un virtualenv en dehors de $ dir, cela fonctionnait bien.

Bizarre.

L'une des raisons possibles pour lesquelles virtualenv pip ne fonctionnera pas est si l'un des dossiers parents avait de l'espace dans son nom en le /Documents/project name/app renommant pour /Documents/projectName/apprésoudre le problème.

Je suis tombé sur le même problème où pip dans venv fonctionne toujours comme pip global.
Après avoir cherché de nombreuses pages, je le comprends de cette façon.
1. Créez un nouveau venv par virtualenv avec l'option "--no-site-packages"

virtualenv --no-site-packages --python=/xx/xx/bin/python my_env_nmae

veuillez noter que bien que l'option "--no-site-packages" soit vraie par défaut depuis la 1.7.0 dans le fichier doc de virtualenv, mais je l'ai trouvée ne fonctionnant pas à moins que vous ne la définissiez manuellement. Afin d'obtenir un pur venv, je suggère fortement d'activer cette option 2. Activez le nouvel env que vous avez créé

source ./my_env_name/bin/activate

3. Vérifiez votre emplacement pip et l'emplacement python et assurez-vous que ces deux commandes sont sous environnement virtuel

pip --version
which python

4. Utilisez pip sous virtual env pour installer des packages sans interruption des packages globaux

pip install package_name

Je souhaite que cette réponse vous aide!

Voici la liste de toutes les options d' installation de pip - je n'ai trouvé aucune -Eoption ' ', peut-être que la version plus ancienne l'avait. Ci-dessous, je partage une utilisation et un fonctionnement de l'anglais clair virtualenvpour les prochains utilisateurs SO.

Tout semble bien, acceptez d'activer le virtualenv( foo). Tout ce qu'il fait, c'est nous permettre d'avoir plusieurs environnements python (et différents), c'est-à-dire différentes versions de Python, ou différentes versions de Django, ou tout autre package Python - au cas où nous aurions une version précédente en production et que nous souhaitions tester la dernière version de Django avec notre application.

En bref, créer et utiliser (activer) un environnement virtuel ( virtualenv) permet d'exécuter ou de tester notre application ou de simples scripts python avec différents interpréteurs Python, par exemple Python 2.7 et 3.3 - peut être une nouvelle installation (en utilisant l' --no-site-packagesoption) ou tous les packages existants / dernière configuration (en utilisant l' --system-site-packagesoption). Pour l'utiliser, nous devons l'activer:

$ pip install djangova l'installer dans les packages de site globaux, et obtenir de la même manière les pip freezenoms des packages de sites globaux.

tandis que dans le répertoire venv (foo), l'exécution $ source /bin/activateactivera venv ie maintenant tout ce qui est installé avec pip ne sera installé que dans l'environnement virtuel, et ce n'est que maintenant que pip freeze ne donnera pas la liste des paquets python globaux du site. Une fois activé:

$ virtualenv --no-site-packages foo       
New python executable in foo/bin/python
Installing setuptools............done.
$ cd foo
$ source bin/activate 
(foo)$ pip install django

(foo)avant que le $signe n'indique que nous utilisons un environnement python virtuel, c'est-à-dire que toute chose avec pip - install, freeze, uninstall sera limitée à ce venv, et aucun effet sur l'installation / les packages Python globaux / par défaut.

Mon problème était les versions pipet python3. Pour la dernière version d' djangoinstallation, pip3est nécessaire. Mon problème a donc été résolu après la création de l'environnement virtuel à l'aide des commandes suivantes:

> virtualenv --python=python3 venv
> source venv/bin/activate
> which pip3 #should be different from /usr/local/bin/pip3
...<some-directory>/venv/bin/pip3