virtualenv --no-site-packages et pip trouvent-ils encore des packages globaux?
J'avais l'impression que virtualenv --no-site-packages créerait un environnement Python complètement séparé et isolé, mais cela ne semble pas être le cas.
Par exemple, python-Django est 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, le pip -E foo install ci-dessus est supposé réinstaller une nouvelle version de Django. De plus, si je dis à pip de geler l'environnement, je reçois beaucoup de paquets. Je m'attendrais à ce que pour un nouvel environnement avec --no-site-packages, ce soit 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 ...
Est-ce que je comprends mal comment --no-site-packages est censé fonctionner?
J'avais un problème comme celui-ci, jusqu'à ce que je réalise (bien avant d'avoir découvert virtualenv) que j'étais allé ajouter des répertoires à PYTHONPATH dans mon fichier .bashrc. Comme cela faisait déjà un an, je n'y ai pas pensé tout de suite.
Finalement, j'ai trouvé que, pour une raison quelconque, pip -E ne fonctionnait pas. Cependant, si j'active réellement virtualenv et utilise easy_install fourni par virtualenv pour installer pip, puis utiliser pip directement depuis l'intérieur, il semble fonctionner comme prévu et n'afficher que les packages dans virtualenv
Je sais que la question est très ancienne, mais pour ceux qui arrivent ici cherchent une solution:
N'oubliez pas de activez virtualenv (source bin/activate) avant d'exécuter pip freeze. Sinon, vous obtiendrez une liste de tous les packages globaux.
Vous devez vous assurer que vous exécutez le binaire pip 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'option --no-site-packages:
$ 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 freeze à partir de la pip nouvellement créée:
$ mytest/bin/pip freeze
argparse==1.3.0
wheel==0.24.0
Mais si nous utilisons la variable globale pip, voici ce que nous obtenons:
$ pip freeze
...
pyxdg==0.25
...
range==1.0.0
...
virtualenv==13.1.2
Autrement dit, tous les packages que pip a installés dans l’ensemble du système. En vérifiant which pip nous obtenons (du moins dans mon cas) quelque chose comme /usr/local/bin/pip, ce qui signifie que lorsque nous faisons pip freeze, il appelle ce binaire au lieu de mytest/bin/pip.
--no-site-packages devrait, comme son nom l'indique, supprimer le répertoire site-packages standard de sys.path. Tout ce qui reste dans le chemin standard de Python y restera.
Efface temporairement la PYTHONPATH avec:
export PYTHONPATH=
Puis créez et activez l'environnement virtuel:
virtualenv foo
. foo/bin/activate
Seulement à ce moment-là:
pip freeze
Un problème similaire peut se produire sous Windows si vous appelez des scripts directement en tant que script.py, qui utilise ensuite l’ouvre-porte par défaut de Windows et ouvre Python en dehors de l’environnement virtuel. L'appeler avec python script.py utilisera 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 renommez un répertoire parent.
Je suis tombé sur le même problème où pip in venv fonctionne toujours en tant que pip global.
Après avoir parcouru de nombreuses pages, je le découvre de cette façon.
1. Créer 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 true par défaut depuis 1.7.0 dans le fichier doc de virtualenv, mais j’ai constaté que cela ne fonctionnait pas si vous ne le définissiez pas manuellement. Pour obtenir un résultat pur, je vous suggère fortement d'activer cette option. 2. Activez le nouvel env que vous avez créé.
source ./my_env_name/bin/activate
- Vérifiez l’emplacement de votre pip et de l’emplacement python et assurez-vous que ces deux commandes sont sous environnement virtuel.
pip --version
which python
- Utilisez pip sous virtual env pour installer des packages gratuitement depuis l'interruption des packages globaux
pip install package_name
Souhaitez que cette réponse vous aide!
Une des raisons possibles pour que virtualenv pip ne fonctionne pas est si l'un des dossiers parent avait un espace dans son nom /Documents/project name/app Le renommer en /Documents/projectName/app résout le problème.
Voici la liste de tous les install options - du pip. Je n’ai trouvé aucune option '-E', elle est peut-être plus ancienne. Ci-dessous, je partage une utilisation simple de l'anglais et le travail de virtualenv pour les prochains utilisateurs SO.
Tout semble aller pour le mieux, acceptez d’activer la virtualenv (foo). Cela nous permet simplement d’avoir plusieurs environnements (différents), c’est-à-dire différentes versions de Python, différentes versions de Django, ou tout autre paquet Python - dans le cas où une version antérieure est en production et que nous voulons tester la dernière version de Django avec notre logiciel. 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ètes Python, c’est-à-dire Python 2.7 et 3.3 - peut être une nouvelle installation (avec l’option --no-site-packages) ou tous les packages. depuis la dernière/existante configuration (en utilisant l'option --system-site-packages). Pour l'utiliser, nous devons l'activer:
$ pip install Django l'installera dans les packages de site globaux, et de même, obtenir le pip freeze donnera les noms des packages de site globaux.
alors que dans le répertoire venv (foo), l'exécution de $ source /bin/activate activera venv, c'est-à-dire que tout ce qui est installé avec pip ne sera installé que dans l'environnement virtuel, et que seul le gel gel ne donnera pas la liste des paquets python de paquets site-global globaux. 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 le signe $ indique que nous utilisons un environnement python virtuel, c’est-à-dire que tout ce qui concerne pip-install, freeze, désinstaller sera limité à cette liste et aucun effet sur les packages/installations Python globaux/par défaut.
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 a bien fonctionné.
Bizarre.