+1, bestätigt mit Mac OS X 10.7.3 und Python 2.7.1

Ein bisschen nervig, wäre toll, eine Lösung zu haben

Wir können eine virtuelle Umgebung mit Leerzeichen im Namen erstellen (siehe # 278), aber easy_install und pip stolpern später darüber:

% 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

Ich bin auch hier, um zu bestätigen, dass dies ein Problem mit OS X ist (10.8 hier). Wenn Sie die Variable VIRTUAL_ENV und shebangs in bin bearbeiten, können Sie sie zum Laufen bringen, aber eine neue Umgebung verschluckt alle Leerzeichen in einem Pfad. Dies ist ein großes Problem für OS X, da das Startlaufwerk normalerweise den Namen "Macintosh HD" trägt und jeder Pfad mit "/ Volumes / Macintosh HD ..." beginnt.

Der Hack, den ich benutze, funktioniert wie folgt.

bin / aktivieren:

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

bin / pip und bin / easy_install:

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

Pip scheint zu arbeiten, nachdem er den Raum im Pfad verlassen hat.

Warum war das geschlossen? Es ist immer noch ein großes Problem. Bearbeiten Sie meinen Fehler, es ist noch offen

Diese Ausgabe ist noch offen.

Ich konnte dies umgehen, indem ich einen symbolischen Link von meinem Home-Verzeichnis zu dem Verzeichnis erstellte, in dem ich arbeiten wollte (das ansonsten ein Leerzeichen enthielt).

Ich sehe das auch, weil Mac. Ich umgehe das, indem ich die Shebang-Zeile in den Skripten manuell auf! # / Usr / bin / env python und alle Werke bearbeite. Wie bereits erwähnt, muss dies jedoch mit jeder neuen Umgebung und allen in der Umgebung installierten zusätzlichen Skripten erfolgen.
Es scheint, dass dies eine einfache Lösung im Code sein sollte, um entweder aus dem Leerzeichen zu entkommen oder / usr / bin / env zu verwenden, wenn is_darwin. Da ich jedoch so ziemlich ein Neuling bin, könnte ich mich irren.

Dies ist nicht nur für Macs, sondern Teil der Spezifikation / des Verhaltens von * nix-Systemen.

Sie können keine Leerzeichen im ersten Argument der Shebang-Zeile haben (sie werden stattdessen in separate Argumente umgewandelt), und normalerweise ist auch kein Escape / Quoting zulässig.

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

Ich weiß, ich bin auch mit Anaconda auf dieses Problem gestoßen. Es ist nur endemisch mit Mac, weil der Laufwerksname das Leerzeichen enthält.

Es sieht so aus, als würde dies durch # 611 korrigiert. Wurde die Wirksamkeit dieser Pull-Anfrage überprüft?

So nervig, sollte so schnell wie möglich behoben werden.

Siehe den Link @Ivoz gepostet, dies ist eine Unix-Einschränkung. # 611 funktioniert möglicherweise für einige Unix-Varianten, wenn sie Backslash-Escapezeichen in einer Shebang-Zeile unterstützen, aber es ist nicht klar, welche Versionen dies tun (und der Code tut dies nur blind, ohne zu überprüfen - was das Problem zwar nicht schlimmer macht, aber gewonnen hat). t auch nicht helfen, wenn es nicht unterstützt wird ...)

Es ist in der Tat wahr, dass dies ein Ergebnis der Art und Weise ist, wie Unix mit Shebang-Linien umgeht, aber wenn # 611 das Problem für einige Systeme behebt und das Problem für andere nicht verschlimmert, wäre das immer noch eine Verbesserung?

Wenn das stimmt, dann ja. Aber ich kann # 611 nicht kommentieren, da ich kein Unix-Entwickler bin. Es könnte Fälle geben, in denen es die Dinge noch schlimmer macht, ich weiß es einfach nicht. Entschuldigung, ich kann nicht mehr helfen.

Fair genug. # 611 muss wahrscheinlich genauer untersucht und auf Randfälle getestet werden.

Noch schlimmer: Unter Windows wird der Standard-Jenkins-Pfad mit demselben Fehler unterbrochen:
FATAL: Leerzeichen sind im Pfad des Python-Interpreters nicht zulässig: C: \ Programme (x86) \ Jenkins \ shiningpanda \ jobs \ c3418983virtualenvs \ d41d8cd9

Ich war gerade von diesem Problem betroffen. Den Anweisungen von StackOverflow folgend, gelang es mir, pip zum Laufen zu bringen , indem ich nur die erste Zeile auf #!/usr/bin/env python

Ich bin mir jedoch nicht sicher, ob diese Lösung in allen Fällen funktioniert ... Ich meine, ich bin nicht sicher, welcher Python ausgeführt wird

Wenn Sie den Shebang der installierten Skripte in "env python" ändern, funktionieren sie nur in einer aktivierten virtuellen Umgebung. Die Skripte wurden mit expliziten absoluten Pfaden generiert, sodass sie immer den Python im venv verwenden und somit die installierten Pakete finden, die von den Skripten benötigt werden.

Mein Vorschlag wäre, dass jemand (wahrscheinlich jemand, der von diesem Problem betroffen ist, aber mindestens jemand auf einer Plattform, die das Problem hat und auch eine Möglichkeit zur Lösung hat) eine Pull-Anfrage bereitstellt, die eine Prüfung implementiert, die wie folgt lautet:

• Wenn wir Leerzeichen im Pfadnamen haben,
• und wir sind auf Plattform XXX,
• Schreiben Sie dann die Shebang-Zeile mit dem folgenden Escapezeichen, um die Leerzeichen zu verarbeiten.
• In allen anderen Fällen greifen Sie auf das aktuelle Verhalten zurück.

Weitere Ergänzungen könnten dann von interessierten Parteien vorgenommen werden, indem lediglich zusätzliche Plattformprüfungen hinzugefügt werden.

Im Idealfall wäre es schön, einen Kommentar mit einem Link zur Dokumentation hinzuzufügen, der bestätigt, wie Plattform XXX Pfade mit Leerzeichen unterstützt, damit zukünftige Betreuer einen Verweis haben, anhand dessen sie prüfen können. Persönlich ist mir nicht klar, welche Korrekturen funktionieren und wo:

1. Die Diskussion hier legt nahe, dass doppelte Anführungszeichen unter OSX funktionieren. Hängt dies jedoch von der genauen OSX-Version ab?
2. In # 611 wurden Escape-Leerzeichen mit Backslashes verwendet, aber es gab keine Bestätigung, für welches Betriebssystem es sich handelte (Linux? Eine bestimmte Kernel-Version? Eine bestimmte Distribution?)

Beachten Sie, dass keine solchen plattformspezifischen Varianten /usr/bin/env . Wie @merwok betonte, führt dies zu einer Änderung des Verhaltens - der Shebang ist absichtlich so geschrieben, dass das Skript ausgeführt werden kann, ohne die Umgebung zu aktivieren.

Das Hinzufügen einiger Tests, um sicherzustellen, dass das Verhalten wie erwartet ist (einschließlich des Prinzips, dass es zurückfällt, wenn wir uns nicht auf einer speziell anerkannten Plattform befinden), wäre ebenfalls äußerst nützlich, aber es wäre auch fummelig, da es das Monkeypatching beinhalten würde Ermöglichen Sie das Testen auf Plattform XXX, wenn Sie nicht tatsächlich auf dieser Plattform ausgeführt werden.

@pfmoore Wie ich bereits erwähnt habe, war ich kürzlich von diesem Problem betroffen und verwende Linux Mint 18. Ich habe noch nie mit Virtualenv beigetragen, aber ich bin derzeit bei Python Brasil und wir haben einen Tag, der Sprints gewidmet ist ein Versuch!

Laut https://lists.gnu.org/archive/html/bug-bash/2008-05/msg00052.html funktioniert es nicht, mit Backslashes oder Anführungszeichen zu entkommen

Experimentell kann ich überprüfen, ob das Escapezeichen mit Backslashes oder Anführungszeichen unter OSX 10.11.6 nicht funktioniert.

virtualenv sollte sich von kernelabhängigen Shebangs fernhalten. Ich habe Linux-, XNU- (MacOS-Kernel), FreeBSD-, OpenBSD- und NetBSD-Quellcodes überprüft. Keiner von ihnen kann mit Leerzeichen in Shebang umgehen.

Verwenden Sie keine Leerzeichen, bevor es eine Lösung gibt.

Ich reiche einen Patch ein, der eine Warnung für das neue venv von Python 3 hinzufügt, das virtualenv ziemlich ähnlich ist, aber von @vsajip abgelehnt wird: http://bugs.python.org/issue28446. In der Tat ist es nicht Pythons Schuld, sondern die eines Betriebssystems. Vielleicht kann dieses Problem geschlossen werden?

Beachten Sie als zusätzlichen Datenpunkt das Verhalten unter Windows, das wie erwartet zu sein scheint:

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

C: \ Users \ Vinay> "\ Temp \ aaa bbb \ Scriptspip" - Version
pip 6.0.8 aus C: \ Temp \ aaa bbb \ lib \ site-packages (Python 3.4)

C: \ Users \ Vinay> pyzzer -i "\ Temp \ aaa bbb \ Scriptspip.exe"
Es gibt einen Launcher.
Shebang: #! "C: \ Temp \ aaa bbb \ Scripts \ python.exe"

Archivinhalt:
__main__.py

C: \ Users \ Vinay> "\ Temp \ aaa bbb \ Scripts \ python" -m pip install -U pip
Sie verwenden pip Version 6.0.8, jedoch ist Version 9.0.1 verfügbar.
Sie sollten ein Upgrade über den Befehl 'pip install --upgrade pip' in Betracht ziehen.
Pip von https://pypi.python.org/ [...] / pip-9.0.1-py2.py3-none-any.whl sammeln # md5 = 297 [...]
Verwenden von zwischengespeicherten pip-9.0.1-py2.py3-none-any.whl
Gesammelte Pakete installieren: pip
Vorhandene Installation gefunden: pip 6.0.8
Deinstallation von pip-6.0.8:
Pip-6.0.8 erfolgreich deinstalliert

Pip-9.0.1 erfolgreich installiert

C: \ Users \ Vinay> "\ Temp \ aaa bbb \ Scriptspip" - Version
pip 9.0.1 aus C: \ Temp \ aaa bbb \ lib \ site-packages (Python 3.4)
`` `

Ja, virtualenv-Skripte unter Windows funktionieren, wenn distlib in PC / launcher.c ein eigenes Shebang-Protokoll definiert. Vielleicht kann POSIX etwas Ähnliches haben - einen Shebang-Parser für den Benutzerbereich anstelle von unzuverlässigen Kerneln.

Ein Shebang-Parser für den Benutzerbereich anstelle unzuverlässiger Kernel

Ich bin mir nicht sicher, warum Bash dies nicht kann (zum Beispiel) - ich denke nicht, dass es eine Kernel-Space-Sache ist.

Shebangs werden im Kernelraum behandelt, da sie außerhalb von Shells verwendet werden können sollten.

Technische Details:
Auf UNIX-ähnlichen Systemen (Linux, Mac, * BSD, ...) wird über fork () und exec () ein neues Programm erstellt. exec () ähnelt CreateProcess () unter Windows, das ein neues Programm ausführt. Auf UNIX-ähnlichen Systemen ruft exec () schließlich den Systemaufruf execve () auf. Die letztere Funktion ist in Kerneln implementiert, so dass das Shebang-Parsing in Kerneln durchgeführt wird.
Es kann auch nicht in C-Bibliotheken implementiert werden, oder statisch verknüpfte Programme oder Programme, die Systemaufrufe direkt verwenden (über int 80 oder sysenter usw.), funktionieren nicht.

Vielleicht sollten wir einfach die Schaffung einer virtuellen Umgebung mit Leerzeichen im Pfad verbieten. Es wird sowieso nicht wie erwartet funktionieren

Shebangs werden im Kernelraum behandelt, da sie außerhalb von Shells verwendet werden können sollten

Ja, aber konnte eine Shell das Parsen nicht selbst durchführen, wenn der Systemaufruf ENOEXEC zurückgab? Mir ist klar, dass es eine Dose Würmer sein könnte ...

Interessanter Leckerbissen - die Kernelfunktionalität unter Linux scheint vom langjährigen Python-Committer Martin von Löwis geschrieben worden zu sein :-)

Diese Seite war auch eine interessante Lektüre: http://www.in-ulm.de/~mascheck/various/shebang/

Ja, aber konnte eine Shell das Parsen nicht selbst durchführen, wenn der Systemaufruf ENOEXEC zurückgab?

IMO unterschiedliche Semantik zwischen Shells und dem zugrunde liegenden Kernel würde sowohl bei Benutzern als auch bei Entwicklern viel Verwirrung stiften. Derzeit analysieren mindestens bash und zsh, wenn execve () fehlschlägt, jedoch nur zur besseren Fehlerberichterstattung, ohne einen Fallback bereitzustellen.

Interessanter Leckerbissen - die Kernelfunktionalität unter Linux scheint vom langjährigen Python-Committer Martin von Löwis geschrieben worden zu sein :-)

Interessant! Das habe ich nicht bemerkt :) Auch danke für das zusätzliche Material. Während das Lesen des Kernel-Quellcodes der schnellste Weg ist, sind solche Dokumente immer noch hilfreich.

Über @fbidus Idee:

Vielleicht sollten wir einfach die Schaffung einer virtuellen Umgebung mit Leerzeichen im Pfad verbieten. Es wird sowieso nicht wie erwartet funktionieren

Das Erstellen virtueller Umgebungen mit fragilen Pfaden ist nützlich, um Eckfälle bei der Pfadbehandlung zu testen. In diesem Beispiel wird gezeigt, wie Kernel beschädigt werden. Meine Idee ist es, Warnungen hinzuzufügen, anstatt zu verbieten, genau wie der Patch, den ich auf http://bugs.python.org/issue28446 gepostet habe

Ich denke, # 994 "Pip schlägt mit Speicherplatz im virtuellen Pfad fehl" ist ein Duplikat dieses Problems.

Ich möchte den Kommentar von https://github.com/pypa/virtualenv/issues/997#issuecomment -270681253 wiederholen. Und in diesem Sinne ist # 1014 "Nicht kompatibel mit einem Verzeichnis mit Emojis im Pfad" ein weiteres Beispiel dafür, dass virtualenv durch fragiles Kernel-Shebang-Parsing beschädigt wird. Ich wette, das Problem tritt tatsächlich bei Nicht-ASCII-Zeichen im Pfad auf.

Vielleicht sollten wir alle drei Aspekte der Analyse von fragilem Kernel-Shebang in einem Problem zusammenfassen, damit wir sicher sein können, dass ein Fix Leerzeichen, Länge und Nicht-ASCII-Zeichen im Pfad der virtuellen Umgebung adressieren kann? Ich nominiere dieses Problem, weil es das älteste ist.

Während wir an einem Fix arbeiten, ist es meiner Meinung nach gut, wenn virtualenv eine Warnung druckt, wenn Sie aufgefordert werden, eine Umgebung in einem Pfad zu erstellen, der a) Leerzeichen enthält, b) zu lang ist oder c) Nicht-ASCII-Zeichen enthält. Ein Satz in einer Dokumentation würde auch helfen.

Ich wette, das Problem tritt tatsächlich bei Nicht-ASCII-Zeichen im Pfad auf.

Ich glaube, der Grund für # 1014 liegt eher in virtualenv als im Kernel. Ich habe einen Patch, der ein ziemlich ähnliches Problem bei # 900 behebt.

Hallo zusammen,
Das ist super nervig und eine enorme Zeitverschwendung aufgrund von etwas scheinbar Einfachem (zumindest aus einfachem Grund).

Wie wäre es mit einem Umbenennen (wenn möglich) oder der Verwendung von Links (Erstellen eines Verzeichnisses wie /virtualenvs/python3.5 ohne Speicherplatz und anschließendes Zulassen eines weichen Links zum ursprünglichen Verzeichnis?)

Erstellen eines Verzeichnisses wie /virtualenvs/python3.5 ohne Speicherplatz

Ein anderes Projekt virtualenvwrapper hat etwas ganz Ähnliches getan.

etwas scheinbar so Einfaches (zumindest einfache Ursache).

Beides ist nicht einfach. Die Ursache hängt mit den Kernel-Parsing-Codes zusammen, und für eine Problemumgehung ist eine Shebang-Behandlung für den Benutzerbereich erforderlich.

Es ist immer noch ein Problem 6 Jahre später?

Dieses Problem hat mich vor 2 Wochen gestolpert. Ja, das ist immer noch ein Problem.

Da es sich eher um ein Unix-Problem als um ein Virtual-Env-Problem handelt, ist es unwahrscheinlich, dass es "behoben" wird, wenn die Unix-Kernel-Beschränkung nicht aufgehoben wird ...

Der erste Fehler bei virtualenv besteht darin, dass virtualenv Shell-ausführbare Dateien mithilfe einer bestimmten Unix-Kernelfunktion implementiert hat, obwohl diese Funktion Einschränkungen aufweist, die routinemäßig Probleme für virtualenv-Benutzer verursachen. Virtualenv könnte dies beheben, indem ein anderer Mechanismus für Shell-ausführbare Dateien verwendet wird. Der zweite Fehler bei virtualenv besteht darin, keine Dokumentation darüber zu haben, wie Benutzer virtualenv verwenden sollten, um den ersten Fehler zu umgehen (erstellen Sie eine virtualenv nur auf kurzen Pfaden mit Nur-ASCII-Zeichen und ohne Leerzeichen). Der dritte Fehler bei virtualenv besteht darin, dass es keinen Mechanismus gibt, der Fälle erkennt, in denen der Benutzer einen Pfad für virtualenv auswählt, der den ersten Fehler auslöst, und eine hilfreiche Warnmeldung ausgibt. Virtualenv-Mitarbeiter können viel tun, um die Situation zu verbessern.

@JDLH Über Ihren ersten "Fehler": Er wird nicht von virtualenv, sondern von distlib behandelt, und es gibt eine Implementierung unter https://bitbucket.org/pypa/distlib/pull-requests/31/. Ich hoffe, ich könnte Zeit haben, die Interna von distlib zu studieren und auf Vinay Sajips Kommentare richtig zu antworten, aber leider nicht.

Der erste Fehler bei virtualenv besteht darin, dass virtualenv Shell-ausführbare Dateien mithilfe einer bestimmten Unix-Kernelfunktion implementiert hat

@JDLH Dies ist nicht spezifisch für virtualenv - _all_ Unix-Skriptdateien (dh Dateien mit Shebang-Zeilen) verwenden diese Kernelfunktion - und es gibt keinen zwingenden Grund, virtualenv (oder irgendetwas anderes) neu zu erfinden Eine völlig neue Methode zum Versenden von Skripten, wenn der vorhandene Mechanismus so weit verbreitet und gut verstanden ist. Wenn Sie ein Skript von Hand schreiben würden, das Leerzeichen im Interpreterpfad enthält (kein virtualenv beteiligt), würde es das gleiche Problem aufweisen.

Virtualenv-Mitarbeiter können viel tun, um die Situation zu verbessern.

Es gibt wahrscheinlich viele Aufrufe zur Zeit der Mitwirkenden. Dieses Problem betrifft die relativ geringe Anzahl von Fällen, in denen lange Pfade / Pfade mit Leerzeichen verwendet werden. Vielleicht könnten einige der betroffenen Benutzer den Mitwirkenden helfen, ihnen zu helfen, indem sie einen Patch vorschlagen, der bei der Erkennung und Warnung hilft? Nur eine Idee.

@ yan12125 distlib ermöglicht es einem, die ausführbare Datei in der Shebang-Zeile anzugeben, wie man möchte. Die Kernel-Beschränkung für Leerzeichen / lange Zeilen wird von Linux-Entwicklern aufgrund der Abwärtskompatibilität möglicherweise nie behoben. Man könnte einfach eine benutzerdefinierte Zeichenfolge für die ausführbare Shebang-Datei bereitstellen (die ein verallgemeinertes Äquivalent zum Mozilla-Skript-Hack enthält), und distlib sollte sie in das Skript schreiben, damit man damit nur als distlib experimentieren kann

Dies ist nicht spezifisch für virtualenv

@vsajip Dies ist eine wahre Aussage - andere Software verwendet denselben Shebang-Mechanismus, den virtualenv gewählt hat -, aber es geht am eigentlichen Punkt dieses Problems vorbei. Es gibt nichts an dem Wert, den virtualenv bietet, was die Verwendung des Shebang erfordert. virtualenv könnte einen anderen Mechanismus verwenden, aber es hat den Shebang gewählt, und somit erbt virtualenv wirklich die Einschränkung des Shebang.

Es gibt keinen zwingenden Grund für virtualenv (oder irgendetwas anderes), eine völlig neue Methode zum Versenden von Skripten neu zu erfinden

Ich denke, Sie sagen, dass die Probleme der Menschen, die im Laufe der Jahre auf dieses Problem gestoßen sind, nicht "zwingend" sind. Ich denke, der Grund, warum so viele Menschen dieses Problem im Laufe der Jahre finden und kommentieren, ist, dass sie die Probleme als "zwingend" empfinden. Das tue ich auf jeden Fall.

Vielleicht könnten einige der betroffenen Benutzer den Mitwirkenden helfen, ihnen zu helfen, indem sie einen Patch vorschlagen, der bei der Erkennung und Warnung hilft? Nur eine Idee.

Ich habe das Wort "Mitwirkende" gewählt, um sowohl die Stalwarts, die den größten Teil der Arbeit an virtualenv erledigen, als auch die Besucher wie mich einzuschließen, die dieses Problem als überzeugend genug empfinden, um an einer Verringerung seiner Auswirkungen zu arbeiten. Es ist fair zu sagen, dass wir, die das Problem zwingend finden, einen Patch beisteuern sollten.

Es wäre hilfreich, wenn die Stalwarts, die virtualenv gut kennen, vielversprechende Ansätze vorschlagen könnten. Wenn ich eine Warnmeldung für den Benutzer einfügen wollte, der virtualenv ~/my\ long\ path\ with\ spaces , wo sollte sich dieser Code am besten befinden? Gibt es nicht offensichtliche Einschränkungen für einen solchen Patch, den die Stalwarts teilen könnten, um ein Hindernis für den Besucher zu beseitigen, der an seinem ersten Beitrag arbeitet? Haben die Stalwarts historische Einwände gegen die Annahme eines solchen Patches? (Ich meine, ich kann nicht die erste Person sein, die daran gedacht hat, eine Warnmeldung hinzuzufügen. Es muss einen Grund geben, warum dies noch nicht geschehen ist.)

Es gibt einen bekannten Pfad, der Leerzeichen enthält und nicht geändert werden kann: /Users/iulian/Library/Mobile Documents/com~apple~CloudDocs . Jeder, der einige Skripte mit virtualenv in iCloud verwalten möchte, stößt auf dieses Problem.

Es wäre hilfreich, wenn die Stalwarts, die virtualenv gut kennen, vielversprechende Ansätze vorschlagen könnten.

Wenn wir welche wüssten, hätten wir dieses Problem wahrscheinlich nicht so lange ungelöst gelassen, angesichts der Menge an Kritik, die wir dafür zu bekommen scheinen :-(

Wenn ich eine Warnmeldung für den Benutzer einfügen wollte, der virtualenv ~ / my \ long \ path \ mit \ Leerzeichen eingibt, wo sollte sich dieser Code am besten befinden?

Sie können zunächst den Argument-Parsing-Code betrachten und eine Prüfung hinzufügen, sobald der Pfad ermittelt wurde.

Gibt es nicht offensichtliche Einschränkungen für einen solchen Patch, den die Stalwarts teilen könnten, um ein Hindernis für den Besucher zu beseitigen, der an seinem ersten Beitrag arbeitet?

Sie können meistens gefunden werden, indem Sie die Problemliste hier nach den verschiedenen Kommentaren durchsuchen, die im Laufe der Jahre zu diesem und anderen Problemen abgegeben wurden. Zunächst müssen Sie jedoch keine Pfade ablehnen, wenn sie funktionieren - und das bedeutet, herauszufinden, welche Einschränkungen das Betriebssystem hat auferlegt. Diese variieren drastisch zwischen den Systemen. Windows erlaubt Leerzeichen und lange Dateinamen, einige Unix-Systeme erlauben Leerzeichen, einige benötigen Pfade mit Leerzeichen, einige haben sehr kurze Längenbeschränkungen (32 Zeichen?), Einige länger, ... Viele Einschränkungen sind nicht gut dokumentiert und sehr wenige Mitwirkende haben Zugriff auf ausreichende Systeme, um alle Möglichkeiten testen zu können, um die verfügbaren Dokumente zu ergänzen.

Haben die Stalwarts historische Einwände gegen die Annahme eines solchen Patches?

Nein, außer "Nehmen Sie nicht an, dass es so einfach ist, wie Sie auf den ersten Blick denken, und ignorieren Sie nicht alle verschiedenen (manchmal ziemlich obskuren) Systeme, die wir unterstützen müssen".

Wenn jemand dies versuchen möchte - und sich bewusst sein sollte, dass dies nicht etwas ist, das ich persönlich als "ersten Beitrag" empfehlen würde -, sollte er zunächst die gesamte in den verschiedenen Ausgaben verfügbare Geschichte lesen (einige) verknüpft von diesem, andere wahrscheinlich nicht, einige wahrscheinlich auf dem Pip-Tracker und vielleicht sogar dem Distlib- oder Setuptool-Tracker) und fassen in einer neuen PR die Einschränkungen zusammen, die von verschiedenen Betriebssystemen auferlegt werden. Schlagen Sie als Dokumentations-Patch vor, dass "wenn diese Bedingungen nicht erfüllt sind, die von virtualenv verwendeten Shebang-Header nicht wie erwartet funktionieren und virtualenv daher das Erstellen von Umgebungen in Verzeichnissen, die nicht den angegebenen Bedingungen entsprechen, nicht unterstützt". Die PR kann eine Codeänderung enthalten, um zu warnen, wenn die dokumentierten Bedingungen nicht erfüllt sind, oder dies als zukünftige Arbeit vorschlagen (soweit ich mich erinnere, ist es ziemlich schwierig, die Systemdetails genau genug zu überprüfen, um zu wissen, welche Grenzwerte gelten - betrachten Sie "Ubuntu" mit einem gepatchten Kernel "...). Persönlich wäre ich mit einer Warnung einverstanden, die nur bekannte Fälle kennzeichnet, in denen Dinge fehlschlagen würden, und schweigt, wenn es nicht sicher ist. Aber ich würde zu diesem Zeitpunkt auch mit einem Nur-Dokumente-Patch zurechtkommen.

Sie müssten dann Überprüfungen Ihres Patches von Personen erhalten, die Zugriff auf die von Ihnen abgedeckten Systeme haben. Wie bereits erwähnt, können die Kernentwickler hier nicht wirklich helfen, da keiner von uns (zum Beispiel) FreeBSD, OpenBSD oder Solaris verwendet. oder ...

Sie können auch nur einen Teiljob ausführen und eine PR erstellen, die Dokumente und eine Warnung nur für (z. B.) OSX hinzufügt. Ich weiß nicht, ob dies die Beschwerden über dieses Problem stoppen würde (ich habe kein Gefühl dafür, auf welchen Systemen dies am häufigsten auftritt), aber vielleicht würde es ausreichen. Möglicherweise ist einer der Kernentwickler, der OSX verwendet, damit einverstanden, dies zusammenzuführen.

Hilft das?

Vielleicht verstehe ich etwas nicht, aber konnte dieses Problem nicht gelöst werden, indem (zum Beispiel) bin/pip enthalten wurde

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

und dann das aktuelle pip Skript auf real-pip ? Ich verstehe nicht, warum wir den Shebang direkt verwenden müssen.

@ raxod502 Ich nehme an, Sie wissen, dass dies unter Windows nicht funktionieren würde. Ich denke auch, dass die "normale" Beschwörung, die in der zweiten Zeile benötigt wird, komplexer ist als die, die Sie geben (obwohl ich persönlich nicht weiß warum). Sie können wahrscheinlich den richtigen Ansatz über eine Websuche finden. Was würde bei Ihrem Ansatz für Pfade mit " oder $ Zeichen passieren?

Vorausgesetzt, Sie können diese Art von Problem angehen, besteht der nächste Schritt wohl darin, dass Sie eine PR einreichen (gemäß den obigen Kommentaren), und wir können Einzelheiten dazu erörtern. Sie müssten mindestens einen der VirtualEv-Core-Committer benötigen, der unter Unix arbeitet. Als Windows-Benutzer wäre ich nicht bereit, eine Unix-spezifische PR wie diese selbst zusammenzuführen.

@pfmoore
vorgeschlagene Lösung von @ raxod502 könnte auch unter Windows mit einer .bat-Skriptdatei funktionieren, afaik?

@gst Kurze Antwort, nein. Eine lange Antwort finden Sie unter http://paul-moores-notes.readthedocs.io/en/latest/wrappers.html. Im Laufe der Jahre gab es viele Diskussionen zu diesem Punkt, und jedes Mal hat jemand eine andere Lösung als eine gefunden Exe Wrapper, es hatte Probleme.

Denken Sie in diesem Fall daran, dass dieses Problem unter Windows nicht besteht . Es gibt also absolut keinen Grund, etwas in der Windows-Umgebung zu ändern - jede Änderung darf nur auf Unix beschränkt werden.

Danke für die gute Antwort :)

Anders als bei einem Exe-Wrapper gab es Probleme.

persönlich kann ich damit leben (wenn ich müsste).

Ich habe distlib aktualisiert, um lange Pfade und Pfade mit Leerzeichen zu verarbeiten. Ich habe den Patch von Harald Nordgren nicht direkt verwendet (es gab einige Probleme - z. B. keine Tests), aber der Ansatz ist der gleiche - ich habe '/ bin / sh' als ausführbare Datei verwendet. pip / virtualenv Betreuer möchten möglicherweise testen, nachdem sie die aktuelle Version des distlib Repositorys lokal verkauft haben.

Die Entwicklungsversion von pip bietet jetzt diese neuere Version von distlib an, was bedeutet, dass pip jetzt Leerzeichen in Verzeichnisnamen einwandfrei verarbeitet.

Soweit ich weiß, wird dieses Problem behoben, sobald die nächste Version von pip und eine virtualenv-Version erstellt wurden. Jede neu erstellte virtualenv unterstützt Leerzeichen im Pfad, ebenso wie von pip installierte Binärdateien (außer möglicherweise in einigen skurrilen Fällen wie setuptools) 'Wrapper, die nicht direkt von pip installiert werden).

Ich habe gerade angefangen, gvfs zu verwenden, um Samba-Freigaben im Benutzerbereich bereitzustellen und zu finden, dass virtualenv / pip usw. aufgrund von Interpunktion in den von gvfs generierten Bereitstellungspfaden beschädigt wurden.

Es gibt keine Leerzeichen in den Pfaden, aber viele andere Dinge, um virtualenv / pip usw. in die Knie zu zwingen und zu versuchen, in einem Verzeichnis wie zu laufen

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

Soweit ich sehen kann, gibt es derzeit in gvfs keine Option, um Interpunktion in den Pfaden der generierten Mountpunkte zu verhindern. Meine einzige Problemumgehung besteht darin, niemals eine virtuelle Umgebung auf einem gvfs-Mount zu erstellen, was ein wenig traurig erscheint

@pradyunsg Gibt es einen Zeitplan für die nächste Pip-Veröffentlichung? Der letzte war vor über einem Jahr , und es scheint ein bisschen dumm zu sein, so lange darauf zu warten, dass diese wirklich einfache Lösung in virtualenv angezeigt wird.

Hi @ raxod502!

Ja, wir wollen es bald rausbringen. Die Sache ist, dass wir wenig Zeit für Entwickler haben, um PEP 518 herauszubringen, was wir tun möchten. Es kann vorkommen, dass es einen Pip 10 ohne PEP 518 gibt, aber auch hier kommt es darauf an, die Zeit zu finden, um den Plan darauf abzustimmen.

Es scheint, dass dieser Fehler durch Pip 10.0.0 behoben wurde , veröffentlicht am 14.04.2018. Genau genommen das Update war in distlib 0.2.6 , die in pip mit ihrer weiterverkauft wurde PR4819 im Oktober 2017 , die ersten in pip 10.0.0b2 erschien.

Der zugrunde liegende Fix scheint in distlibs Commit 9285cca zu sein . Wie vsajip hier am 28. Mai 2017 kommentierte , folgt der Ansatz der Idee von Harald Nordgren: Verwenden Sie weiterhin einen einfachen Shebang für einfache Fälle (das Betriebssystem ist nicht Posix oder der Pfad ist kurz genug und hat keine Leerzeichen), sondern für die Verwendung nicht einfacher Fälle Stattdessen ein /bin/sh exec -Befehl, der die langen oder Leerzeichen enthaltenden Pfade verarbeiten kann.

Ich habe einen kurzen Test unter Mac OS X 10.11.6 durchgeführt, eine virtuelle Umgebung auf einem langen Pfad mit Leerzeichen erstellt und dann pip3 install aufgerufen, und es scheint zu funktionieren. Ich habe nicht vollständig getestet, dass alles, was in diesem Fehler beschrieben wird, auf jedem Betriebssystem behoben ist.

Nach dem Upgrade von pip von 9.0.1 auf 18.1 (sie haben auf eine kalenderbasierte Version umgestellt) und virtualenv von 15.0.1 auf 16.0.0 mit Ubuntu 16.04.5 LTS scheint das Problem behoben zu sein:

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

Jetzt funktionieren alle pip -Befehle ordnungsgemäß in virtuellen Umgebungen mit Leerzeichen im Stammpfad.

Wie von @JLDH und @gandie bestätigt , wurde dieses Problem jetzt behoben. Die neuesten Versionen von pip und virtualenv funktionieren ordnungsgemäß zusammen, wenn im Stammverzeichnis einer virtualenv Leerzeichen vorhanden sind.

Schließen Sie das! Vielen Dank für die Arbeit am zugrunde liegenden Fix @vsajip!

Altes Ticket: aber warum nicht

! / usr / bin / env python?

@rirl , ich denke, es ist unwahrscheinlich, dass das Hinterlassen eines Kommentars zu einer geschlossenen Ausgabe Ihre Aufmerksamkeit auf sich