Impossible d'installer via pip avec Virtualenv

Question

Voici l'erreur que j'obtiens lorsque j'exécute pip :

serkan$ rm -r mysite
serkan$ pwd
/Users/serkan/Desktop/Python Folder
serkan$ virtualenv mysite 
New python executable in mysite/bin/python
Installing setuptools............done.
Installing pip...............done.
serkan$ source mysite/bin/activate
(mysite)serkan$ pip install pinax
-bash: /Users/serkan/Desktop/Python Folder/mysite/bin/pip: "/Users/serkan/Desktop/Python: bad interpreter: No such file or directory
(mysite)serkan$ python pip install pinax
python: can't open file 'pip': [Errno 2] No such file or directory
(mysite)serkan$ python pip install Pinax
python: can't open file 'pip': [Errno 2] No such file or directory
(mysite)serkan$ python pip install Pinax
python: can't open file 'pip': [Errno 2] No such file or directory
(mysite)serkan$ python pip install Pinax
python: can't open file 'pip': [Errno 2] No such file or directory
(mysite)serkan$ python pip 
python: can't open file 'pip': [Errno 2] No such file or directory
(mysite)serkan$ pip
-bash: /Users/serkan/Desktop/Python Folder/mysite/bin/pip: "/Users/serkan/Desktop/Python: bad interpreter: No such file or directory
(mysite)serkan$ pip install Pinax
-bash: /Users/serkan/Desktop/Python Folder/mysite/bin/pip: "/Users/serkan/Desktop/Python: bad interpreter: No such file or directory
(mysite)serkan$

Answer 1

J'ai eu la même erreur dans RedHat . Python 2.7.3 est configuré et réalisé par moi-même.

[root@Ifx installer]# pip install Django
-bash: /usr/local/bin/pip: /usr/local/bin/python2.7: bad interpreter: Permission denied

Solution : Sur /usr/local/bin/pip remplacer la première ligne #!/usr/local/bin/python2.7 avec votre chemin d'accès actuel à Python #!/root/installer/Python-2.7.5/python

Answer 2

J'ai eu un problème très similaire sur mon Windows 7 machine et a lutté quelques jours avec ça. Les deux chemins, vers ma distribution python et vers mon VE avait des espaces en elle. Quelques mois auparavant, il fonctionnait bien. J'ai trouvé la note suivante sur le site de virtualenv :

**Windows Notes**
[...] To create a virtualenv under a path with spaces in it on Windows, you’ll need the win32api library installed.

Les étapes suivantes m'ont conduit au succès :

1. Assurez-vous que j'ai utilisé pip pour installer virtualenv et que c'est la dernière version (pip-7.1.0). Résultat : échec .
2. Installez win32api. Résultat : échec (bien qu'il y ait eu une erreur à la toute fin du processus d'installation).
3. Essayez d'installer mon VE dans un chemin sans espaces. Résultat : échec .
4. Réinstaller ma distribution python Anaconda dans le chemin qui ne contenait pas les crochets "[" et "]". VE avait des espaces dans le chemin. Résultat : échec .
5. Réinstaller ma distribution Anaconda python sur le chemin qui ne contenait pas non plus d'espaces. Le dossier VE avait toujours des espaces dans le chemin. Résultat : succès !

Donc au moins l'installation d'Anaconda (python) est simple, le chemin non pollué par l'espace était crucial . Peut-être que l'installation de win32api était également importante. Je ne suis pas sûr.

Answer 3

J'ai trouvé ceci en faisant une recherche sur Google alors que je rencontrais le même problème et j'ai trouvé ceci très utile. virtualenv a maintenant un --relocatable qui réécrira la commande shebang en #!/usr/bin/env <the_python_version_you_used_to_create_the_virtualenv> . Elle s'accompagne de certaines réserves, aussi veillez à lire la documentation pour en comprendre les implications :

https://virtualenv.pypa.io/en/stable/userguide/#making-environments-relocatable

Vous devez utiliser la même syntaxe pour relocaliser le virtualenv que celle utilisée lors de sa création, sinon la version python risque d'être écrasée. Cela fonctionnera comme prévu...

virtualenv --python=python3.5 env-test
virtualenv --relocatable --python=python3.5 env-test

alors qu'il en résultera #!/usr/bin/env python2.7 (du moins sur mon environnement local)...

virtualenv --python==python3.5 env-test
virtualenv --relocatable env-test

Answer 4

Pour mon cas, désactiver l'environnement et source bin/activate fonctionne à nouveau.

Il semble que le contenu de mon dossier ait les mêmes noms de sous-dossiers que ceux générés par le système de gestion des dossiers. virtualenv comme bin, lib, etc. Et après avoir copié mes fichiers, réactivez l'environnement et laissez virtualenv pour mettre à jour les nouvelles informations.

Answer 5

Si c'est sous Windows, cela peut être dû à des changements de dll (par d'autres logiciels). L'installation d'openSSL devrait le résoudre. https://slproweb.com/products/Win32OpenSSL.html

Il renouvellera automatiquement les dll vers ses versions les plus récentes.