Pourquoi les paquets de liste de pip de virtualenv sont-ils dans mon répertoire lib/python2.7?

Question

Dans ma maison, j'ai un répertoire nommé lib/python2.7 (il y a en fait cinq répertoires comme ça, pour différentes versions de python). Comme il s'agit d'un hébergement partagé (Webfaction), ce répertoire est fondamental pour moi. Là, j'ai des choses comme virtualenv et virtualenvwrapper installé, puisque en tant que client d'un hébergement partagé, je n'ai pas accès à sudo et l'installation de paquets globaux.

Cependant, lorsque je crée un virtualenv:

$ mkvirtualenv myenvironment 
$ workon myenvironment 
$ which pip 
# outputs the myenvironment's path to pip 
$ pip freeze 

La commande affiche la liste complète des paquets sous mon lib/python2.7 (ce qui inclut les mêmes forfaits virtualenv et paquets en conflit, j'ai ... en raison de l'héritage .. . les raisons). Cela m'agace aussi si je veux installer un paquet qui est le nom d'un paquet dans lib/python2.7 puisqu'il ne me permet pas de le mettre à jour.

à l'intérieur de l'environnement workon, j'essaie de vérifier si le PYTHONPATH a des trucs bizarres, mais il est vide:

$ echo $PYTHONPATH 
# shows a blank line 

Il est également vide si je tente cette commande de tout environnement virtuel.

Il semblerait que --no-site-packages soit la valeur par défaut mais ne résout qu'une partie du problème. Cela signifie que: pip freeze | wc -l affiche une valeur inférieure dans un environnement que lors d'une exécution globale, hors de tout environnement, ce qui m'indique que certains paquets déjà fournis sont exclus et proviennent de l'hébergement lui-même (et non installé par moi depuis , encore une fois, l'hébergement est partagé et je n'ai pas accès à l'espace global).

Ma question est: Comment puis-je résoudre ce problème? Je veux que mon virtualenv liste pas les paquets dans $HOME/lib/python2.7

S'il vous plaît éviter duper-linking à this question, rien était utile que là-bas et ne toujours pas une réponse acceptée. J'ai écrit cette question après avoir lu et essayé chaque solution dans cette question

Answer 1

Je pense que vous devez spécifier la version python. Vous pouvez spécifier la version python avec lequel vous voulez créer un environnement virtuel en utilisant la commande comme

virtualenv -p /usr/bin/python3.4 virt/virtname --no-site-packages 

Parce que lorsque vous spécifiez pas une version python, virtualenv crée un environnement avec pythonv2.7 et donc tous les paquets finissent dans le dossier mentionné.

Answer 2

Trouvé la solution après creusage profond. Il s'agit d'une Webfaction personnalisée mais cela peut s'appliquer à toute installation de ce type si le problème survient.

Le cœur du problème est que Webfaction a configuré un fichier sitecustomize.py pour nous. Le fichier est situé à /usr/local/lib/pythonX.Y/sitecustomize.py et ajoute par lui-même le contenu de ~/lib/pythonX.Y (et conditionnellement le contenu de n'importe quelle application python sous ~/webapps si vous travaillez sous un répertoire pour exécuter un script python).

Même lorsque l'exécutable python de virtualenv est différent, il charge le fichier sitecustomize.py chaque fois qu'il s'exécute comme le fait l'exécutable python de base.

La solution de contournement ici? Créer un sitecustomize.py vide dans votre virtualenv pour remplacer l'autre:

touch ~/.virtualenvs/yourvenv/lib/pythonX.Y/sitecustomize.py 

Et cela fonctionnera. Take this as reference if you are stuck here like I was

Remarques: Remplacez X.Y dans chaque cas par la version correspondante que vous utilisez. De plus, n'oubliez pas: Vous ne pouvez pas supprimer ou modifier la base sitecustomize.py puisque vous êtes dans un hébergement partagé, dans ce cas. Cependant, l'écrasement fonctionnera pour chaque cas tant que vous le faites pour chaque virtualenv que vous voulez.