+1, confirmé avec Mac OS X 10.7.3 et Python 2.7.1

Un peu ennuyeux, ce serait génial d'avoir une solution

Nous sommes capables de créer un virtualenv avec des espaces dans le nom (voir # 278), mais easy_install et pip trébuchent dessus plus tard:

% virtualenv "foo bar"
New python executable in foo bar/bin/python
Installing setuptools............done.
Installing pip...............done.
% ./foo\ bar/bin/easy_install nose
zsh: ./foo bar/bin/easy_install: bad interpreter: "/tmp/cfl/foo: no such file or directory
127 % ./foo\ bar/bin/pip install nose 
zsh: ./foo bar/bin/pip: bad interpreter: "/tmp/cfl/foo: no such file or directory

Je suis également ici pour confirmer qu'il s'agit d'un problème avec OS X (10.8 ici). Si vous modifiez la variable VIRTUAL_ENV et les shebangs dans bin, vous pouvez le faire fonctionner, mais un nouvel env s'étouffe sur tous les espaces d'un chemin. Ce qui est un gros problème pour OS X, étant donné que le lecteur de démarrage est généralement nommé "Macintosh HD", donc chaque chemin commence par "/ Volumes / Macintosh HD ..."

Le hack que j'utilise fonctionne comme suit.

bin / activer:

VIRTUAL_ENV='/Volumes/Macintosh\ HD/path/to/my/project'

bin / pip et bin / easy_install:

#!"/Volumes/Macintosh\ HD/path/to/my/project/venv/bin/python"

Pip semble fonctionner après avoir échappé à l'espace du chemin.

Pourquoi cela a-t-il été fermé? C'est toujours un problème. modifier mon erreur, elle est toujours ouverte

ce problème est toujours ouvert.

J'ai pu contourner ce problème en créant un lien symbolique de mon répertoire personnel vers celui dans lequel je voulais travailler (qui autrement contenait un espace).

Je vois cela aussi parce que Mac. Je contourne cela en éditant manuellement la ligne shebang dans les scripts en! # / Usr / bin / env python et tout fonctionne. Cependant, comme d'autres l'ont mentionné, cela doit être fait avec chaque nouvel env et tout script supplémentaire installé dans l'environnement.
Il semble que cela devrait être une solution facile dans le code pour échapper à l'espace ou utiliser / usr / bin / env si is_darwin. Cependant, puisque je suis à peu près un noob à cela, je peux me tromper.

Ce n'est pas seulement pour mac, cela fait essentiellement partie de la spécification / du comportement des systèmes * nix.

Vous ne pouvez pas avoir d'espaces dans le premier argument de la ligne shebang (ils seront transformés en arguments séparés à la place), et normalement, les échappements / guillemets ne sont pas autorisés non plus.

http://lists.gnu.org/archive/html/bug-bash/2008-05/msg00053.html

Je sais, j'ai aussi rencontré ce problème avec l'anaconda. C'est juste endémique avec Mac parce que le nom du lecteur contient un espace blanc.

Il semble que cela serait corrigé par # 611. Y a-t-il eu un examen de l'efficacité de cette pull request?

Si ennuyeux, devrait être corrigé dès que possible.

Voir le lien @Ivoz posté, ceci est une limitation Unix. # 611 pourrait fonctionner pour certaines variantes d'Unix, si elles prennent en charge les échappements de backslash dans une ligne shebang, mais on ne sait pas quelles versions le font (et le code le fait aveuglément sans vérifier - ce qui ne rendra pas le problème pire, mais a gagné '' t aide non plus s'il n'est pas pris en charge ...)

Il est en effet vrai que cela est le résultat de la façon dont unix gère les lignes shebang, mais si # 611 résout le problème pour certains systèmes et n'aggrave pas le problème pour d'autres, serait-ce encore une amélioration?

Si c'est vrai, alors oui. Mais je ne peux pas commenter # 611 car je ne suis pas un développeur Unix. Il peut y avoir des cas où cela aggrave les choses, je ne sais tout simplement pas. Désolé, je ne peux pas être plus utile.

C'est suffisant. # 611 doit probablement être examiné plus attentivement et testé pour les cas marginaux.

Pire encore: sous Windows, il se casse sur le chemin Jenkins par défaut avec la même erreur:
FATAL: les espaces ne sont pas autorisés dans le chemin de l'interpréteur Python: C: \ Program Files (x86) \ Jenkins \ shiningpanda \ jobs \ c3418983virtualenvs \ d41d8cd9

J'étais juste affecté par ce problème. En suivant les instructions que j'ai trouvées sur StackOverflow , j'ai réussi à faire fonctionner pip en définissant simplement la première ligne sur #!/usr/bin/env python

Je ne suis pas sûr, cependant, si cette solution fonctionne dans tous les cas ... Je veux dire, je ne suis pas sûr de savoir quel Python sera exécuté

Changer le shebang des scripts installés en «env python» signifie qu'ils ne fonctionneront que dans un virtualenv activé. Les scripts ont été générés avec des chemins absolus explicites afin qu'ils utilisent toujours le Python dans le venv, et trouvent ainsi les paquets installés nécessaires aux scripts.

Ma suggestion serait que quelqu'un (probablement quelqu'un affecté par ce problème, mais au minimum quelqu'un sur une plate-forme qui a le problème et qui a également un moyen de le résoudre) fournisse une pull request mettant en œuvre une vérification du type:

• Si nous avons des espaces dans le chemin,
• et nous sommes sur la plateforme XXX,
• puis écrivez la ligne shebang avec l'échappement suivant pour gérer les espaces.
• Dans tous les autres cas, revenez au comportement actuel.

D'autres ajouts pourraient alors être apportés par les parties intéressées en ajoutant simplement des vérifications de plate-forme supplémentaires.

Idéalement, il serait bien d'inclure un commentaire avec un lien vers la documentation qui confirme comment la plate-forme XXX prend en charge les chemins avec des espaces, afin que les futurs responsables aient une référence à vérifier. Personnellement, je ne sais pas exactement quels correctifs fonctionnent et où:

1. la discussion ici suggère que les guillemets fonctionnent sous OSX, mais cela dépend-il de la version précise d'OSX?
2. Dans # 611, des espaces d'échappement avec des barres obliques inverses ont été utilisés, mais il n'y avait aucune confirmation quant au système d'exploitation pour lequel il s'agissait (Linux? Une version spécifique du noyau? Une distribution spécifique?)

Notez qu'aucune variante spécifique à la plate-forme ne doit utiliser /usr/bin/env . Comme @merwok l'a souligné, cela entraîne un changement de comportement - le shebang est délibérément écrit pour permettre l'exécution du script _sans_ l'activation de l'environnement.

Ajouter des tests pour être sûr que le comportement est comme prévu (y compris le principe selon lequel il retombe lorsque nous ne sommes pas sur une plate-forme spécifiquement reconnue) serait également extrêmement utile, mais ce serait aussi délicat, car cela impliquerait un monkeypatching à autorisez les tests pour la plate-forme XXX lorsque vous ne l'utilisez pas réellement.

@pfmoore Comme je l'ai mentionné, j'ai été récemment affecté par ce problème et j'utilise Linux Mint 18. Je n'ai jamais contribué avec Virtualenv mais je suis actuellement chez Python Brasil et nous aurons une journée consacrée aux sprints, je pourrais le donner un essai!

échapper avec des barres obliques inverses ou des guillemets ne fonctionnera pas, selon https://lists.gnu.org/archive/html/bug-bash/2008-05/msg00052.html

Expérimentalement, je peux vérifier que l'échappement avec des barres obliques inverses ou des guillemets ne fonctionne pas avec OSX 10.11.6.

virtualenv doit rester à l'écart des shebangs dépendants du noyau. J'ai vérifié les codes sources Linux, XNU (noyau de macOS), FreeBSD, OpenBSD et NetBSD. Aucun d'entre eux ne peut gérer les espaces en shebang.

Avant qu'il y ait un correctif, n'utilisez pas d'espaces.

Je soumets un correctif qui ajoute un avertissement pour le nouveau venv de Python 3, qui est assez similaire à virtualenv mais rejeté par @vsajip : http://bugs.python.org/issue28446. En effet, ce n'est pas la faute de Python mais celle d'un système d'exploitation. Peut-être que ce problème peut être résolu?

Comme point de données supplémentaire, notez le comportement sous Windows, qui semble être comme prévu:

`` `C: \ Utilisateurs \ Vinay> \ python34 \ python -m venv" \ Temp \ aaa bbb "

C: \ Users \ Vinay> "\ Temp \ aaa bbb \ Scriptspip" --version
pip 6.0.8 à partir de C: \ Temp \ aaa bbb \ lib \ site-packages (python 3.4)

C: \ Users \ Vinay> pyzzer -i "\ Temp \ aaa bbb \ Scriptspip.exe"
Il y a un lanceur.
Shebang: #! "C: \ Temp \ aaa bbb \ Scripts \ python.exe"

Contenu de l'archive:
__main__.py

C: \ Users \ Vinay> "\ Temp \ aaa bbb \ Scripts \ python" -m pip install -U pip
Vous utilisez la version 6.0.8 de pip, mais la version 9.0.1 est disponible.
Vous devriez envisager la mise à niveau via la commande 'pip install --upgrade pip'.
Collecte de pip depuis https://pypi.python.org/ [...] / pip-9.0.1-py2.py3-none-any.whl # md5 = 297 [...]
Utilisation de pip-9.0.1-py2.py3-none-any.whl mis en cache
Installation des packages collectés: pip
Installation existante trouvée: pip 6.0.8
Désinstallation de pip-6.0.8:
Pip-6.0.8 a bien été désinstallé

Pip-9.0.1 installé avec succès

C: \ Users \ Vinay> "\ Temp \ aaa bbb \ Scriptspip" --version
pip 9.0.1 à partir de C: \ Temp \ aaa bbb \ lib \ site-packages (python 3.4)
''

Oui, les scripts virtualenv sous Windows fonctionnent car distlib définit son propre protocole shebang dans PC / launcher.c. Peut-être que POSIX peut avoir quelque chose de similaire - un analyseur de shebang de l'espace utilisateur au lieu de noyaux peu fiables.

un analyseur de shebang de l'espace utilisateur au lieu de noyaux peu fiables

Je ne sais pas pourquoi Bash ne peut pas faire cela (par exemple) - je ne pense pas que ce soit un problème d'espace noyau.

Les shebangs sont gérés dans l'espace noyau car ils devraient être utilisables en dehors des shells.

Détails techniques:
Sur les systèmes de type UNIX (Linux, Mac, * BSD, ...), un nouveau programme est créé via fork () et exec (). exec () est similaire à CreateProcess () sous Windows, qui exécute un nouveau programme. Sur les systèmes de type UNIX, exec () appelle finalement l'appel système execve (). Cette dernière fonction est implémentée dans les noyaux, donc l'analyse de shebang est effectuée dans les noyaux.
Il ne peut pas non plus être implémenté dans les bibliothèques C, ou les programmes liés statiques ou les programmes utilisant directement des appels système (via int 80 ou sysenter, etc.) ne fonctionneront pas.

Peut-être devrions-nous simplement interdire la création d'un environnement virtuel avec des espaces dans le chemin. Cela ne fonctionnera pas comme prévu de toute façon

Les shebangs sont gérés dans l'espace noyau car ils devraient être utilisables en dehors des shells

Oui, mais un shell ne pourrait-il pas effectuer lui-même l'analyse si l'appel système retournait ENOEXEC ? Je me rends compte que ça pourrait être une boîte de vers ...

Information intéressante - la fonctionnalité du noyau sous Linux semble avoir été écrite par Martin von Löwis, un auteur de longue date de Python :-)

Cette page était également une lecture intéressante: http://www.in-ulm.de/~mascheck/various/shebang/

Oui, mais un shell ne pourrait-il pas effectuer lui-même l'analyse si l'appel système retournait ENOEXEC ?

Une sémantique différente de l'OMI entre les shells et le noyau sous-jacent apporterait beaucoup de confusion aux utilisateurs ainsi qu'aux développeurs. Actuellement, au moins bash et zsh analysent quand execve () échoue, mais seulement pour un meilleur rapport d'erreur, sans fournir de solution de secours.

Information intéressante - la fonctionnalité du noyau sous Linux semble avoir été écrite par Martin von Löwis, un auteur de longue date de Python :-)

Intéressant! Je n'ai pas remarqué que :) Merci également pour le matériel supplémentaire. Bien que la lecture du code source du noyau soit le moyen le plus rapide, ces documents sont toujours utiles.

À propos de l'idée de @fbidu :

Peut-être devrions-nous simplement interdire la création d'un environnement virtuel avec des espaces dans le chemin. Cela ne fonctionnera pas comme prévu de toute façon

La création d'environnements virtuels avec des chemins fragiles est utile pour tester les cas d'angle dans la gestion des chemins. Dans cet exemple, il montre comment les noyaux sont cassés. Mon idée est d'ajouter des avertissements au lieu d'interdire, tout comme le correctif que j'ai publié sur http://bugs.python.org/issue28446

Je pense que # 994 "Pip échoue avec de l'espace dans le chemin virtualenv" est un double de ce problème.

Je veux répéter le commentaire de https://github.com/pypa/virtualenv/issues/997#issuecomment -270681253, "virtualenv est cassé avec l'analyse fragile du noyau shebang." Et dans cet esprit, # 1014 "Non compatible avec un répertoire ayant des emojis dans son chemin" est un autre exemple de virtualenv interrompu par une analyse fragile du noyau shebang. Je parie que le problème se produit avec des caractères non ASCII dans le chemin, en fait.

Peut-être devrions-nous rassembler les trois aspects de l'analyse de shebang du noyau fragile en un seul problème, afin que nous puissions être sûrs qu'un correctif peut adresser les espaces, la longueur et les caractères non ASCII dans le chemin virtualenv? Je propose ce numéro, car c'est le plus ancien.

Pendant que nous travaillons sur un correctif, je pense qu'il serait bon que virtualenv affiche un avertissement lorsqu'il est demandé de créer un environnement dans un chemin qui a) a des espaces, b) est trop long ou c) contient des caractères non ASCII. Une phrase dans certains documents aiderait également.

Je parie que le problème se produit avec des caractères non ASCII dans le chemin, en fait.

Je crois que la raison de # 1014 est dans virtualenv plutôt que dans le noyau. J'ai un correctif qui corrige un problème assez similaire à # 900.

Salut à tous,
C'est super ennuyeux et une telle perte de temps à cause de quelque chose d'apparemment si simple (raison simple au moins).

Que diriez-vous de renommer (si possible), ou d'utiliser des liens (créer un répertoire tel que /virtualenvs/python3.5 sans espace, puis laisser cela être un lien souple vers le répertoire d'origine?)

création d'un répertoire tel que /virtualenvs/python3.5 sans espace

Un autre projet virtualenvwrapper a fait quelque chose d'assez similaire.

quelque chose d'apparemment si simple (au moins une cause simple).

Ni l'un ni l'autre ne sont simples. La cause est liée aux codes d'analyse du noyau et une solution de contournement nécessite une gestion de l'espace utilisateur.

C'est toujours un problème 6 ans plus tard?

Ce problème m'a fait trébucher il y a 2 semaines. Oui, c'est toujours un problème.

Notez que comme il s'agit d'un problème Unix plutôt que d'un problème virtualenv, il est peu probable qu'il soit "corrigé" à moins que la limitation du noyau Unix ne soit supprimée ...

Le premier bogue de virtualenv est que virtualenv a choisi d'implémenter des fichiers exécutables shell en utilisant une certaine fonctionnalité du noyau Unix, bien que cette fonctionnalité ait des limitations qui causent régulièrement des problèmes aux utilisateurs de virtualenv. Virtualenv pourrait résoudre ce problème en utilisant un mécanisme différent pour les fichiers exécutables shell. Le deuxième bogue de virtualenv est de n'avoir aucune documentation sur la façon dont les utilisateurs devraient utiliser virtualenv afin de contourner le premier bogue (créez un virtualenv uniquement sur des chemins courts avec des caractères ASCII uniquement et sans espace). Le troisième bogue de virtualenv est qu'il n'a pas de mécanisme qui détecte les cas où l'utilisateur choisit un chemin virtualenv qui déclenchera le premier bogue et affichera un message d'avertissement utile. Les contributeurs de virtualenv pourraient faire beaucoup pour améliorer la situation.

@JDLH A propos de votre premier "bug": il n'est pas géré par virtualenv mais distlib, et il y a une implémentation sur https://bitbucket.org/pypa/distlib/pull-requests/31/. J'espère avoir le temps d'étudier les rouages ​​de distlib et de répondre correctement aux commentaires de Vinay Sajip, mais malheureusement je ne le fais pas.

Le premier bogue de virtualenv est que virtualenv a choisi d'implémenter des fichiers exécutables shell en utilisant une certaine fonctionnalité du noyau Unix

@JDLH Ceci n'est pas spécifique à virtualenv - _all_ Les fichiers de script Unix (c'est-à-dire les fichiers avec des lignes shebang) utilisent cette fonctionnalité du noyau - et il n'y a aucune raison impérieuse pour virtualenv (ou quoi que ce soit d'autre) de réinventer une méthode complètement nouvelle d'envoi de scripts, lorsque le mécanisme existant est si largement utilisé et bien compris. Si vous écriviez un script à la main qui avait des espaces dans le chemin de l'interpréteur (aucun virtualenv impliqué), il présenterait le même problème.

Les contributeurs de virtualenv pourraient faire beaucoup pour améliorer la situation.

Il y a probablement de nombreux appels sur le temps des contributeurs. Ce problème affecte le nombre relativement petit de cas où de longs chemins / chemins avec des espaces sont utilisés. Peut-être que certains de ces utilisateurs concernés pourraient aider les contributeurs à les aider en leur proposant un correctif qui faciliterait la détection et les messages d'avertissement? Juste une idée.

@ yan12125 distlib permet de spécifier l'exécutable dans la ligne shebang comme on le souhaite. La limitation du noyau sur les espaces / longues lignes ne sera peut-être jamais corrigée par les développeurs Linux en raison de la compatibilité descendante. On pourrait simplement fournir une chaîne personnalisée pour l'exécutable shebang (incorporant un équivalent généralisé au hack de script Mozilla) et distlib devrait l'écrire dans le script, donc on peut l'expérimenter comme un distlib user (donc sans _need_ pour regarder les internes, AFAICT).

Ce n'est pas spécifique à virtualenv

@vsajip Ceci est une vraie déclaration - d'autres logiciels utilisent le même mécanisme de shebang que virtualenv a choisi - mais il manque le point de ce problème. Il n'y a rien dans la valeur fournie par virtualenv qui exige qu'il utilise le shebang. virtualenv pourrait utiliser un mécanisme différent, mais il a choisi le shebang, et donc virtualenv hérite vraiment de la limitation du shebang.

il n'y a aucune raison impérieuse pour virtualenv (ou quoi que ce soit d'autre) de réinventer une méthode complètement nouvelle de distribution de scripts

Je pense que ce que vous dites, c'est que les problèmes rencontrés par les personnes qui ont rencontré ce problème au fil des ans ne sont pas «impérieux». Je pense que la raison pour laquelle tant de gens trouvent et commentent cette question au fil des ans est qu'ils trouvent les problèmes «impérieux». Je fais certainement.

Peut-être que certains de ces utilisateurs concernés pourraient aider les contributeurs à les aider en leur proposant un correctif qui faciliterait la détection et les messages d'avertissement? Juste une idée.

J'ai choisi le mot «contributeurs» pour inclure à la fois les piliers qui font la plupart du travail sur virtualenv, et les visiteurs comme moi qui trouvent ce problème suffisamment convaincant pour travailler à réduire son impact. Il est juste de dire que nous, qui trouvons le problème convaincant, devrions apporter un correctif.

Il serait utile que les piliers qui connaissent bien virtualenv puissent suggérer des approches prometteuses. Si je voulais insérer un message d'avertissement pour l'utilisateur qui tape virtualenv ~/my\ long\ path\ with\ spaces , où ce code devrait-il mieux résider? Existe-t-il des contraintes non évidentes sur un tel patch, que les piliers pourraient partager, pour supprimer un obstacle au visiteur travaillant sur sa première contribution? Les piliers ont-ils une objection historique à accepter un tel patch? (Je veux dire, je ne peux pas être la première personne à avoir pensé à ajouter un message d'avertissement. Il doit y avoir une raison pour laquelle cela ne s'est pas encore produit.)

Il existe un chemin bien connu qui contient des espaces et ne peut pas être modifié: /Users/iulian/Library/Mobile Documents/com~apple~CloudDocs . Donc, quiconque souhaite gérer certains scripts avec virtualenv dans iCloud se heurte à ce problème.

Il serait utile que les piliers qui connaissent bien virtualenv puissent suggérer des approches prometteuses.

Eh bien, si nous en savions, nous n'aurions probablement pas laissé ce problème non résolu depuis si longtemps, étant donné la quantité de critiques que nous semblons recevoir pour le faire :-(

Si je voulais insérer un message d'avertissement pour l'utilisateur qui tape virtualenv ~ / mon \ long \ chemin \ avec \ espaces, où ce code devrait-il mieux résider?

Vous pouvez commencer par regarder le code d'analyse des arguments, en ajoutant une vérification une fois que le chemin a été déterminé.

Existe-t-il des contraintes non évidentes sur un tel patch, que les piliers pourraient partager, pour supprimer un obstacle au visiteur travaillant sur sa première contribution?

Ils peuvent principalement être trouvés en recherchant dans la liste des problèmes ici les divers commentaires faits à ce sujet et sur d'autres problèmes au fil des ans, mais pour commencer, vous ne devez pas rejeter les chemins lorsqu'ils fonctionneront - et cela signifie déterminer les limites du système d'exploitation. impose. Celles-ci varient considérablement d'un système à l'autre. Windows autorise les espaces et les noms de fichiers longs, certains systèmes Unix autorisent les espaces, certains nécessitent des chemins avec des espaces pour être entre guillemets, certains ont des limites de longueur très courtes (32 caractères?) D'autres plus longues, ... De nombreuses limitations ne sont pas bien documentées, et très peu les contributeurs ont accès à des systèmes suffisants pour pouvoir tester toutes les possibilités suffisamment pour compléter les documents disponibles.

Les piliers ont-ils une objection historique à accepter un tel patch?

Non, à part "ne présumez pas que c'est aussi simple que vous le pensez à première vue, et n'ignorez pas tous les différents systèmes (parfois assez obscurs) que nous devons supporter".

Si quelqu'un veut essayer de le faire - et qu'il doit savoir que ce n'est pas quelque chose que je recommanderais personnellement comme "première contribution" - alors il devrait commencer par lire tout l'historique disponible dans les différents numéros (certains liés à celui-ci, d'autres probablement pas, certains probablement sur le tracker pip et peut-être même les trackers distlib ou setuptools) et résument dans un nouveau PR les contraintes imposées par différents OS. Proposez qu'en tant que correctif de documentation indiquant «à moins que ces conditions ne soient remplies, les en-têtes shebang utilisés par virtualenv ne fonctionneront pas comme prévu, et donc virtualenv ne prend pas en charge la création d'environnements dans des répertoires qui ne correspondent pas aux conditions énoncées». Le PR peut inclure un changement de code pour avertir si les conditions documentées ne sont pas remplies, ou peut le proposer comme travail futur (d'après ce que je me souviens, il est assez difficile d'introspecter les détails du système assez précisément pour savoir quelles limites s'appliquent - considérez "Ubuntu avec un noyau patché "...). Personnellement, je serais d'accord avec un avertissement qui ne signalait que les cas connus où les choses échoueraient, et était silencieux si ce n'était pas sûr. Mais je serais également très bien avec un correctif réservé aux documents à ce stade.

Vous devrez ensuite obtenir des critiques de votre patch auprès des personnes ayant accès aux systèmes que vous couvrez - comme indiqué, les développeurs principaux ne peuvent pas vraiment vous aider ici car aucun de nous n'utilise (par exemple) FreeBSD, OpenBSD ou Solaris, ou ...

Vous pouvez également faire un travail partiel et créer un PR qui ajoute des documents et un avertissement uniquement pour (par exemple) OSX. Je ne sais pas si cela arrêterait les plaintes à propos de ce problème (je ne sais pas quels systèmes cela se produit le plus fréquemment), mais peut-être que ce serait suffisant. Peut-être que l'un des principaux développeurs qui utilise OSX serait d'accord pour fusionner cela.

Est ce que ça aide?

Peut-être que je ne comprends pas quelque chose, mais ce problème ne pourrait-il pas être résolu en ayant (par exemple) bin/pip contenir

#!/bin/sh
"/my/long path/with spaces/pythonx.y" "/path/to/my project/with spaces/venv/bin/real-pip" "$@"

puis en déplaçant le script pip actuel vers real-pip ? Je ne vois pas pourquoi nous devons utiliser le shebang directement.

@ raxod502 Je suppose que vous savez que cela ne fonctionnerait pas sous Windows. Aussi, je pense que l'incantation "normale" nécessaire sur la deuxième ligne est plus complexe que celle que vous donnez (bien que je ne sache pas pourquoi, personnellement). Vous pouvez probablement trouver la bonne approche via une recherche sur le Web. Avec votre approche, que se passerait-il pour les chemins contenant des caractères " ou $ ?

En supposant que vous puissiez aborder ce type de problème, je suppose que la prochaine étape serait pour vous de soumettre un PR (comme indiqué ci-dessus) et nous pouvons débattre des détails à ce sujet. Vous auriez besoin d'impliquer au moins l'un des principaux committers de virtualenv travaillant sur Unix - en tant qu'utilisateur Windows, je ne serais pas disposé à fusionner moi-même un PR spécifique à Unix comme celui-ci.

@pfmoore
La solution proposée par @ raxod502 pourrait également fonctionner sur Windows avec un fichier de script .bat, afaik?

@gst Réponse courte, non. La réponse longue est à http://paul-moores-notes.readthedocs.io/en/latest/wrappers.html Il y a eu de nombreuses discussions sur ce point au fil des ans, et chaque fois que quelqu'un a proposé une solution autre qu'un wrapper exe, il a eu des problèmes.

Dans ce cas, n'oubliez pas que ce problème n'existe pas sous Windows . Il n'y a donc absolument aucune raison de changer quoi que ce soit dans l'environnement Windows - tout changement doit être limité à Unix uniquement.

merci pour une bonne réponse :)

autre qu'un wrapper exe, il a eu des problèmes.

personnellement, je peux vivre avec ça (si je devais le faire).

J'ai mis distlib jour pip / virtualenv responsables peuvent vouloir tester après avoir vendu localement la version actuelle du dépôt distlib .

La version de développement de pip vend désormais cette nouvelle version de distlib, ce qui signifie que pip gère désormais très bien les espaces dans les noms de répertoire.

Si je comprends bien, une fois que la prochaine version de pip et une version virtualenv seront faites, ce problème sera résolu - tout nouveau virtualenv créé prendra en charge les espaces dans le chemin, tout comme les binaires installés par pip (sauf peut-être dans certains cas bizarres comme setuptools 'wrappers qui ne sont pas directement installés par pip).

Je viens de commencer à utiliser gvfs pour monter des partages samba dans l'espace utilisateur et trouver virtualenv / pip etc scuppered à cause de la fonction dans les chemins de montage générés par gvfs.

Il n'y a pas d'espaces dans les chemins, mais beaucoup d'autres choses pour mettre virtualenv / pip etc.

/run/user/1000/gvfs/smb-share:server=bolt,share=eng/projects/msp/mrfbus/land

Pour autant que je puisse voir, il n'y a actuellement aucune option dans gvfs pour empêcher la ponctuation dans les chemins de ses points de montage générés. Ma seule solution est de ne jamais créer un virtualenv sur un montage gvfs, ce qui semble un peu triste

@pradyunsg Y a-t-il un calendrier pour la prochaine version de pip? La dernière date d'il y a plus d'un an , et il semble un peu stupide d'attendre si longtemps que cette solution vraiment simple apparaisse dans virtualenv.

Salut @ raxod502!

Ouais, nous voulons le sortir bientôt. Le fait est que nous manquons de temps pour les développeurs pour sortir la PEP 518, ce que nous voulons faire. Il se peut qu'il y ait un pip 10 sans PEP 518, mais encore une fois, cela dépend de trouver le temps de régler le plan à ce sujet.

Il semble que ce bogue soit corrigé par pip 10.0.0 , publié le 14/04/2018. À proprement parler, le correctif était dans distlib 0.2.6 , qui a été vendu dans pip avec leur PR4819 en octobre 2017, qui est apparu pour la première fois dans pip 10.0.0b2.

Le correctif sous-jacent semble être dans le commit 9285cca de distlib . Comme vsajip l'a commenté ici le 28 mai 2017 , l'approche suit l'idée de Harald Nordgren: continuer à utiliser un simple shebang pour les cas simples (le système d'exploitation n'est pas Posix, ou le chemin est assez court et n'a pas d'espaces), mais pour les cas non simples, utilisez une commande /bin/sh exec place, qui peut gérer les chemins longs ou contenant des espaces.

J'ai fait un test rapide sur Mac OS X 10.11.6, en créant un env virtuel dans un long chemin avec des espaces, puis en invoquant pip3 install , et cela semble fonctionner. Je n'ai pas complètement testé que tout ce qui est décrit dans ce bogue est corrigé sur chaque système d'exploitation.

Après la mise à niveau de pip de 9.0.1 à 18.1 (ils sont passés à la version basée sur le calendrier) et virtualenv de 15.0.1 à 16.0.0 en utilisant Ubuntu 16.04.5 LTS, le problème semble avoir disparu:

sudo pip install --upgrade pip
sudo pip install --upgrade virtualenv

Maintenant, toutes les commandes pip fonctionnent correctement dans les virtualenvs ayant des espaces dans leur chemin racine.

Comme confirmé par @JLDH et @gandie , ce problème est maintenant résolu; avec les dernières versions de pip et virtualenv fonctionnant ensemble correctement lorsque la racine d'un virtualenv contient des espaces.

Fermer ça! Merci pour le travail sur le correctif sous-jacent @vsajip!

Ancien ticket: mais pourquoi pas

! / usr / bin / env python?

@rirl , je pense que laisser un commentaire sur un problème fermé n'attirera probablement pas l'attention de votre idée. Le problème a reçu une solution. Si vous pensez que le nouveau virtulenv, avec cette solution, serait amélioré en faisant les choses différemment, alors vous proposez un nouveau changement. Envisagez d'ouvrir un nouveau numéro, indiquez le changement qui, selon vous, devrait se produire et expliquez pourquoi le changement serait meilleur que le nouveau virtualenv.