+ 1、Mac OS X10.7.3およびPython2.7.1で確認済み

ちょっと面倒ですが、修正していただければ幸いです

名前にスペースを含むvirtualenvを作成することはできますが（＃278を参照）、easy_installとpipは後でつまずきます。

% 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

これがOSX（ここでは10.8）の問題であることを確認するためにもここにいます。 VIRTUAL_ENV変数とビン内のシバンを編集すると、それを機能させることができますが、パス内の任意のスペースで新しいenvがチョークします。 ブートドライブの名前は通常「MacintoshHD」であるため、すべてのパスが「/ Volumes / MacintoshHD ...」で始まることを考えると、これはOSXにとって大きな問題です。

私が使用しているハックは次のように機能します。

ビン/アクティブ化：

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

bin / pipおよびbin / easy_install：

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

パスのスペースをエスケープした後、ピップは機能しているようです。

なぜこれが閉鎖されたのですか？ それはまだ非常に問題です。 私の間違いを編集してください、それはまだ開いています

この問題はまだ開いています。

これを回避して、ホームディレクトリから作業したいディレクトリへのシンボリックリンクを作成することができました（それ以外の場合はスペースがありました）。

Macだから私もこれを見ている。 スクリプトのshebang行を！＃/ usr / bin / env pythonに手動で編集することでこれを回避し、すべてが機能します。 ただし、他の人が言及しているように、これは、新しいenvごとに、およびenvにインストールされている追加のスクリプトを使用して実行する必要があります。
これは、スペースをエスケープするか、is_darwinの場合は/ usr / bin / envを使用するために、コードで簡単に修正できるはずです。 しかし、私はこれにかなり慣れていないので、私は間違っている可能性があります。

これはMacだけのものではなく、基本的に* nixシステムの仕様/動作の一部です。

シバン行の最初の引数にスペースを含めることはできません（代わりに別々の引数に変換されます）。通常、エスケープ/引用も許可されていません。

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

私はアナコンダでもこの問題に遭遇しました。 ドライブ名に空白が含まれているため、これはMacに固有のものです。

これは＃611で修正されるようです。 そのプルリクエストの有効性に関するレビューはありましたか？

とても迷惑ですが、できるだけ早く修正する必要があります。

@Ivozが投稿したリンクを参照してください。これはUnixの制限です。 ＃611は、シバン行でバックスラッシュエスケープをサポートしている場合、一部のUnixバリアントで機能する可能性がありますが、どのバージョンがサポートするかは明確ではありません（そして、コードはチェックせずに盲目的にそれを実行します-確かに問題を悪化させることはありませんが、問題は発生しません」サポートされていない場合も役立ちます...）

これはunixがシバンラインを処理する方法の結果であることは確かですが、＃611が一部のシステムの問題を修正し、他のシステムの問題を悪化させない場合、それでも改善されるでしょうか？

それが本当ならそうです。 しかし、私はUnix開発者ではないので、＃611についてコメントすることはできません。 事態が悪化する場合もあるかもしれませんが、私にはわかりません。 申し訳ありませんが、これ以上お役に立てることはありません。

けっこうだ。 ＃611はおそらく、フリンジケースをより注意深く調べてテストする必要があります。

さらに悪いことに、Windowsでは、デフォルトのJenkinsパスで同じエラーが発生します。
致命的：Pythonインタープリターのパスに空白は許可されていません：C：\ Program Files（x86）\ Jenkins \ shiningpanda \ jobs \ c3418983virtualenvs \ d41d8cd9

私はこの問題の影響を受けました。 StackOverflowで見つけた指示に従って、最初の行を#!/usr/bin/env python設定するだけで、 pip機能させることができました。

ただし、そのソリューションがすべての場合に機能するかどうかはわかりません...つまり、どのPythonが実行されるかはわかりません

インストールされたスクリプトのシバンを「envpython」に変更すると、それらはアクティブ化されたvirtualenvでのみ機能します。 スクリプトは明示的な絶対パスを使用して生成されたため、常にvenvでPythonを使用し、スクリプトに必要なインストール済みパッケージを見つけることができます。

私の提案は、誰か（おそらくこの問題の影響を受ける人ですが、少なくとも問題があり、それを解決する方法もあるプラットフォーム上の誰か）が次の行に沿ってチェックを実装するプルリクエストを提供することです。

• パス名にスペースがある場合、
• プラットフォームXXXを使用しています。
• 次に、スペースを処理するために、次のエスケープを使用してシバン行を記述します。
• 他のすべての場合は、現在の動作にフォールバックします。

その後、プラットフォームチェックを追加するだけで、関係者がさらに追加することができます。

理想的には、プラットフォームXXXがスペース付きのパスをサポートする方法を確認するドキュメントへのリンクを含むコメントを含めて、将来のメンテナがチェックするための参照を持つようにするとよいでしょう。 個人的には、どの修正が機能し、どこで機能するのかわかりません。

1. ここでの議論は、二重引用符がOSXで機能することを示唆していますが、それは正確なOSXバージョンに依存しますか？
2. ＃611では、バックスラッシュ付きのエスケープスペースが使用されましたが、それがどのOS用であるかについての確認はありませんでした（Linux？特定のカーネルバージョン？特定のディストリビューション？）

そのようなプラットフォーム固有のバリアントは/usr/bin/envを使用してはならないことに注意してください。 @merwokが指摘したように、その結​​果、動作が変化します。シェバンは、環境をアクティブ化せずにスクリプトを実行できるように意図的に作成されています。

動作が期待どおりであることを確認するためにいくつかのテストを追加することも非常に便利ですが（特に認識されているプラ​​ットフォーム上にない場合はフォールバックするという原則を含む）、モンキーパッチを適用する必要があるため、面倒です。プラットフォームXXXを実際に実行していないときに、そのプラットフォームのテストを許可します。

@pfmoore先ほど述べたように、私は最近この問題の影響を受け、Linux Mint 18を実行しています。Virtualenvに貢献したことはありませんが、現在Python Brasilにいるので、スプリントに専念する日があります。試してみてください！

https://lists.gnu.org/archive/html/bug-bash/2008-05/msg00052.htmlによると、バックスラッシュまたは引用符を使用したエスケープは機能しません

実験的に、バックスラッシュまたは引用符を使用したエスケープがOSX10.11.6では機能しないことを確認できます。

virtualenvは、カーネルに依存するシバンに近づかないようにする必要があります。 Linux、XNU（macOSのカーネル）、FreeBSD、OpenBSD、NetBSDのソースコードをチェックしました。 それらのどれもシバンのスペースを扱うことができません。

修正する前に、スペースを使用しないでください。

Python 3の新しいvenvの警告を追加するパッチを送信します。これは、virtualenvと非常によく似ていますが、 @ vsajipによって拒否されhttp ： //bugs.python.org/issue28446 。 実際、それはPythonのせいではなく、オペレーティングシステムのせいです。 たぶん、この問題は解決できますか？

追加のデータポイントとして、Windowsでの動作に注意してください。これは、予想どおりのようです。

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

C：\ Users \ Vinay> "\ Temp \ aaa bbb \ Scriptspip" --version
C：\ Temp \ aaa bbb \ lib \ site-packagesからのpip6.0.8（python 3.4）

C：\ Users \ Vinay> pyzzer -i "\ Temp \ aaa bbb \ Scriptspip.exe"
ランチャーがあります。
シバン：＃！ "C：\ Temp \ aaa bbb \ Scripts \ python.exe"

アーカイブの内容：
__main__。py

C：\ Users \ Vinay> "\ Temp \ aaa bbb \ Scripts \ python" -m pip install -U pip
pipバージョン6.0.8を使用していますが、バージョン9.0.1が利用可能です。
'pip install --upgradepip'コマンドを使用してアップグレードすることを検討する必要があります。
https://pypi.python.org/ [...] / pip-9.0.1-py2.py3-none-any.whl＃md5 = 297 [...]からpipを収集してい
キャッシュされたpip-9.0.1-py2.py3-none-any.whlの使用
収集したパッケージのインストール：pip
既存のインストールが見つかりました：pip 6.0.8
pip-6.0.8のアンインストール：
pip-6.0.8が正常にアンインストールされました

pip-9.0.1が正常にインストールされました

C：\ Users \ Vinay> "\ Temp \ aaa bbb \ Scriptspip" --version
C：\ Temp \ aaa bbb \ lib \ site-packagesからのpip9.0.1（python 3.4）
`` `

はい、Windows上のvirtualenvスクリプトは、distlibがPC /launcher.cで独自のシバンプロトコルを定義しているため機能します。 おそらくPOSIXは、信頼性の低いカーネルではなく、ユーザースペースのシバンパーサーという似たようなものを持つことができます。

信頼性の低いカーネルの代わりにユーザースペースシバンパーサー

なぜBashがこれを実行できないのかわかりません（たとえば）-カーネル空間の問題ではないと思います。

シバンはシェルの外で使用できるはずなので、カーネル空間で処理されます。

技術的な詳細：
UNIXライクなシステム（Linux、Mac、* BSD、...）では、fork（）とexec（）を介して新しいプログラムが作成されます。 exec（）は、新しいプログラムを実行するWindowsのCreateProcess（）に似ています。 UNIXライクなシステムでは、exec（）は最終的にシステムコールexecve（）を呼び出します。 後者の関数はカーネルに実装されているため、シバン解析はカーネルで行われます。
Cライブラリにも実装できません。静的にリンクされたプログラムや、システムコールを直接（int 80やsysenterなどを介して）使用するプログラムは機能しません。

たぶん、パスにスペースがある仮想環境の作成を禁止する必要があります。 とにかく期待どおりに動作しません

シバンはシェルの外で使用できるはずなので、カーネル空間で処理されます

はい。ただし、システムコールがENOEXEC返した場合、シェルはそれ自体を解析できません

興味深い一言-Linuxのカーネル機能は、長年のPythonコミッターであるMartinvonLöwisによって書かれたようです:-)

このページも興味深い読み物でした： http ：

はい。ただし、システムコールがENOEXEC返した場合、シェルはそれ自体を解析できません

シェルと基盤となるカーネルの間のIMOの異なるセマンティクスは、開発者だけでなくユーザーにも多くの混乱をもたらします。 現在、少なくともbashとzshは、execve（）が失敗したときに解析を行いますが、エラー報告を改善するためだけであり、フォールバックは提供しません。

興味深い一言-Linuxのカーネル機能は、長年のPythonコミッターであるMartinvonLöwisによって書かれたようです:-)

面白い！ 私はそれに気づかなかった:)また余分な材料に感謝します。 カーネルのソースコードを読むのが最速の方法ですが、そのようなドキュメントはまだ役に立ちます。

@fbiduのアイデアについて：

たぶん、パスにスペースがある仮想環境の作成を禁止する必要があります。 とにかく期待どおりに動作しません

脆弱なパスを使用して仮想環境を作成すると、パス処理のコーナーケースをテストするのに役立ちます。 この例では、カーネルがどのように壊れているかを示しています。 私の考えは、 http：//bugs.python.org/issue28446に投稿したパッチのように、禁止する代わりに警告を追加することです。

＃994「仮想環境パスのスペースでピップが失敗する」はこの問題の複製だと思います。

https://github.com/pypa/virtualenv/issues/997#issuecomment -270681253からのコメントを繰り返したいと思います。「virtualenvは、壊れやすいカーネルシバン解析で壊れています。」 そしてその精神で、＃1014「パスに絵文字が含まれているディレクトリと互換性がない」は、脆弱なカーネルシバン解析によってvirtualenvが壊れているもう1つの例です。 実際、パス内の非ASCII文字で問題が発生することは間違いありません。

壊れやすいカーネルシバン解析の3つの側面すべてを1つの問題にまとめて、1つの修正でvirtualenvパスのスペース、長さ、および非ASCII文字に確実に対処できるようにする必要があるかもしれません。 この問題は最も古いので、私はこの問題を推薦します。

修正に取り組んでいる間、a）スペースがある、b）長すぎる、またはc）ASCII以外の文字があるパスに環境を作成するように求められたときに、virtualenvが警告を出力するのが良いと思います。 一部のドキュメントの文章も役立ちます。

実際、パス内の非ASCII文字で問題が発生することは間違いありません。

＃1014の理由は、カーネルではなくvirtualenvにあると思います。 ＃900で非常によく似た問題を修正するパッチがあります。

こんにちは、みんな、
これは非常に煩わしく、一見非常に単純なもの（少なくとも単純な原因）のために非常に大きな時間の浪費です。

名前を変更する（可能な場合）、またはリンクを使用する（スペースなしで/virtualenvs/python3.5などのディレクトリを作成し、これを元のディレクトリへのソフトリンクにする）のはどうですか？

スペースなしで/virtualenvs/python3.5などのディレクトリを作成する

別のプロジェクトvirtualenvwrapperは、非常によく似た処理を実行しました。

一見とても単純なもの（少なくとも単純な原因）。

どちらも単純ではありません。 原因はカーネル解析コードに関連しており、回避策にはユーザースペースのシバン処理が必要です。

それは6年後もまだ問題ですか？

この問題は2週間前に私をつまずかせました。 はい、それはまだ問題です。

これはvirtualenvの問題ではなくUnixの問題であるため、Unixカーネルの制限が解除されない限り、「修正」される可能性は低いことに注意してください...

最初のvirtualenvのバグは、virtualenvが特定のUnixカーネル機能を使用してシェル実行可能ファイルを実装することを選択したことです。ただし、その機能には、virtualenvユーザーに日常的に問題を引き起こす制限があります。 Virtualenvは、シェル実行可能ファイルに別のメカニズムを使用することでこれを修正できます。 2番目のvirtualenvのバグは、最初のバグを回避するためにユーザーがvirtualenvをどのように使用するかについてのドキュメントがないことです（ASCIIのみの文字と空白のない短いパスでのみvirtualenvを作成します）。 3番目のvirtualenvバグは、ユーザーが最初のバグをトリガーするvirtualenvパスを選択した場合を検出し、役立つ警告メッセージを出力するメカニズムがないことです。 virtualenvの貢献者が状況を改善するためにできることはたくさんあります。

@JDLH最初の「バグ」について：virtualenvではなくdistlibで処理され、https：//bitbucket.org/pypa/distlib/pull-requests/31/に実装があります。 distlibの内部を研究し、Vinay Sajipのコメントに適切に返信する時間があればいいのですが、残念ながら私はそうしません。

最初のvirtualenvのバグは、virtualenvが特定のUnixカーネル機能を使用してシェル実行可能ファイルを実装することを選択したことです。

@JDLHこれはvirtualenv固有のものではありません-_all_ Unixスクリプトファイル（つまり、シバン行のあるファイル）はこのカーネル機能を使用します-そしてvirtualenv （または他のもの）が再発明する説得力のある理由はありません既存のメカニズムが非常に広く使用され、よく理解されている場合、スクリプトをディスパッチするまったく新しい方法。 インタプリタパスにスペースがある（ virtualenv含まない）スクリプトを手動で作成した場合、同じ問題が発生します。

virtualenvの貢献者が状況を改善するためにできることはたくさんあります。

おそらく、寄稿者の時間には多くの呼びかけがあります。 この問題は、長いパス/スペースのあるパスが使用される比較的少数のケースに影響します。 おそらく、影響を受けるユーザーの中には、メッセージの検出と警告に役立つパッチを提案することで、寄稿者が彼らを助けるのを助けることができるでしょうか？ ただのアイデア。

@ yan12125 distlib使用すると、必要に応じてシバン行で実行可能ファイルを指定できます。 空白/長い行のカーネル制限は、下位互換性のため、Linux開発者によって修正されることはおそらくないでしょう。 shebang実行可能ファイル（Mozillaスクリプトハックに相当する一般化されたものを組み込む）のカスタム文字列を提供するだけで、 distlibがスクリプトに書き込む必要があるため、 distlibと同じように試すことができます。

これはvirtualenvに固有のものではありません

@vsajipこれは本当の声明です—他のソフトウェアはvirtualenvが選択したのと同じシバンメカニズムを使用しています—しかしそれはこの問題のポイントを見逃しています。 シェバンを使用することを要求するvirtualenvによって提供される値については何もありません。 virtualenvは別のメカニズムを使用できますが、shebangを選択したため、virtualenvは実際にはshebangの制限を継承します。

virtualenv（または他の何か）がスクリプトをディスパッチするまったく新しい方法を再発明する説得力のある理由はありません

あなたが言っていることは、この問題に長年遭遇した人々が経験した問題は「強制的」ではないということだと思います。 何年にもわたって多くの人がこの問題を見つけてコメントしている理由は、彼らが問題を「やむを得ない」と感じているからだと思います。 私は確かにそうします。

おそらく、影響を受けるユーザーの中には、メッセージの検出と警告に役立つパッチを提案することで、寄稿者が彼らを助けるのを助けることができるでしょうか？ ただのアイデア。

私は「寄稿者」という言葉を選んだのは、virtualenvでほとんどの作業を行う頑固者と、この問題がその影響を減らすのに十分な説得力があると感じる私のような訪問者の両方を含むためです。 問題が説得力があると思う私たちがパッチを提供するべきだと言っても過言ではありません。

virtualenvをよく知っている頑固者が有望なアプローチを提案できれば助かります。 virtualenv ~/my\ long\ path\ with\ spacesと入力したユーザーに警告メッセージを挿入したい場合、そのコードはどこに配置するのが最適ですか？ 最初の貢献に取り組んでいる訪問者から障害を取り除くために、そのようなパッチに、頑固者が共有できる非自明な制約はありますか？ 頑固者はそのようなパッチを受け入れることに歴史的な異議を唱えていますか？ （つまり、警告メッセージを追加することを考えた最初の人になることはできません。まだ行われていない理由があるはずです。）

スペースを含み、変更できない既知のパスが1つあります： /Users/iulian/Library/Mobile Documents/com~apple~CloudDocs 。 そのため、iCloudでvirtualenvを使用してスクリプトを管理したい人は、この問題にぶつかります。

virtualenvをよく知っている頑固者が有望なアプローチを提案できれば助かります。

まあ、もし私たちが何かを知っていれば、そうすることに対して私たちが受けると思われる批判の量を考えると、おそらくこの問題をそれほど長い間未解決のままにしておかなかっただろう:-(

virtualenv〜 / my \ long \ path \ with \ spaceと入力したユーザーに警告メッセージを挿入したい場合、そのコードはどこに配置するのが最適ですか？

まず、引数の解析コードを確認し、パスが決定されたらチェックを追加します。

最初の貢献に取り組んでいる訪問者から障害を取り除くために、そのようなパッチに、頑固者が共有できる非自明な制約はありますか？

これらは主に、ここで問題リストを検索して、この問題や他の問題について長年にわたって行われたさまざまなコメントを検索することで見つけることができますが、最初に、パスが機能するときにパスを拒否する必要はありません-つまり、OSの制限を理解することを意味します課します。 これらはシステム間で大幅に異なります。 Windowsはスペースと長いファイル名を許可し、一部のUnixシステムはスペースを許可し、一部はスペースを引用符で囲むパスが必要、一部は非常に短い長さ制限（32文字？）、一部はより長い、...多くの制限は十分に文書化されておらず、ごくわずかです。寄稿者は、利用可能なドキュメントを補足するのに十分なすべての可能性をテストできる十分なシステムにアクセスできます。

頑固者はそのようなパッチを受け入れることに歴史的な異議を唱えていますか？

いいえ、「一見しただけの単純なものだと思い込まないでください。また、サポートする必要のあるさまざまな（場合によってはかなりあいまいな）システムをすべて無視しないでください」。

誰かがこれを突き刺したいと思っていて、それが私が個人的に「最初の貢献」として推奨するものではないことを知っている必要がある場合は、さまざまな問題で利用可能なすべての履歴を読むことから始める必要があります（一部これからリンクされているものもあれば、おそらくそうではないものもあり、おそらくpipトラッカーやdistlibまたはsetuptoolsトラッカーにあるものもあります）、さまざまなOSによって課せられる制約を新しいPRに要約します。 「これらの条件が満たされない限り、virtualenvによって使用されるshebangヘッダーは期待どおりに機能しないため、virtualenvは、指定された条件に一致しないディレクトリでの環境の作成をサポートしない」と記載されているドキュメントパッチとして提案します。 PRには、文書化された条件が満たされない場合に警告するコード変更を含めることができます。または、これを将来の作業として提案することもできます（私が思い出したように、適用される制限を知るのに十分なほど正確にシステムの詳細を内省することはかなり困難です。「Ubuntu」を検討してください。パッチを適用したカーネルを使用する」...）。 個人的には、物事が失敗する既知のケースにのみフラグを立て、確信が持てない場合は黙っていたという警告で問題ありません。 ただし、この段階ではドキュメントのみのパッチでも問題ありません。

次に、対象のシステムにアクセスできる人からパッチのレビューを取得する必要があります。前述のように、FreeBSD、OpenBSD、Solarisなどを使用している人はいないため、コア開発者はここでは実際には役に立ちません。または..。

また、部分的なジョブを実行して、（たとえば）OSXに対してのみドキュメントと警告を追加するPRを作成することもできます。 それでこの問題に関する苦情が止まるかどうかはわかりませんが（これが最も頻繁に発生するシステムについてはわかりません）、おそらくそれで十分でしょう。 おそらく、OSXを使用するコア開発者の1人はそれをマージしても大丈夫でしょう。

それは役に立ちますか？

おそらく私は何かを理解していませんが、（たとえば） bin/pip含まれていることによってこの問題を解決することはできません

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

次に、現在のpipスクリプトをreal-pipますか？ なぜシェバンを直接使わなければならないのかわかりません。

@ raxod502これはWindowsでは機能しないことを"または$文字を含むパスはどうなりますか？

この種の問題に対処できると仮定すると、次のステップはPRを提出することだと思います（上記のコメントに従って）。その詳細については議論することができます。 Unixで動作するvirtualenvコアコミッターの少なくとも1人を関与させる必要があります-Windowsユーザーとして、私はこのようなUnix固有のPRを自分でマージするつもりはありません。

@pfmoore
@ raxod502によって提案されたソリューションは、.batスクリプトファイルafaikを使用するWindowsでも機能しますか？

@gst短い答え、いいえ。 長い答えはであるhttp://paul-moores-notes.readthedocs.io/en/latest/wrappers.html年間で、この点について多くの議論が行われてきた、と毎回誰かが以外に解決策を打ち出していますexeラッパー、問題がありました。

この場合、この問題はWindowsには存在しないことに注意してください。 したがって、Windows環境で何かを変更する理由はまったくありません。変更はUnixのみに制限するあります。

良い答えのためのthx :)

exeラッパー以外に問題がありました。

個人的に私はそれと一緒に暮らすことができます（私がしなければならなかった場合）。

distlibを更新して、長いパスとスペースのあるパスを処理しました。 Harald Nordgrenのパッチを直接使用しませんでした（テストがないなど、いくつかの問題がありました）が、実行可能ファイルとして「/ bin / sh」を使用する方法は同じです。 pip / virtualenvメンテナは、現在のバージョンのdistlibリポジトリをローカルでベンダー化した後にテストすることをお勧めします。

pipの開発バージョンは、この新しいバージョンのdistlibをベンダーに提供します。つまり、pipはディレクトリ名のスペースを適切に処理するようになりました。

私が理解しているように、pipの次のリリースとvirtualenvのリリースが行われると、この問題は修正されます-作成された新しいvirtualenvは、pipによってインストールされたバイナリと同様にパス内のスペースをサポートします（setuptoolsのような奇妙な場合を除く） 'pipによって直接インストールされないラッパー）。

私はgvfsを使用してユーザースペースにsamba共有をマウントし始めたところですが、gvfsによって生成されたマウントパスの機能が原因でvirtualenv / pipなどが破壊されているのを見つけました。

パスにスペースはありませんが、virtualenv / pipなどを次のようなディレクトリで実行しようとしてひざまずくための他の多くのものがあります

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

私が見る限り、現在gvfsには、生成されたマウントポイントのパスで句読点を防ぐオプションはありません。 私の唯一の回避策は、gvfsマウントにvirtualenvを作成しないことです。これは少し悲しいようです。

@pradyunsg次のpipリリースのタイムラインはありますか？ 最後のものは1年以上前のもので、この本当に単純な修正がvirtualenvに表示されるのを長い間待つのはちょっとばかげているようです。

こんにちは@ raxod502！

ええ、私たちはすぐにそれを出したいです。 問題は、PEP 518を公開するための開発者の時間が不足していることです。これは、私たちがやりたいことです。 PEP518のないpip10がある場合もありますが、これも、計画を確定する時間を見つけるかどうかにかかっています。

このバグがで固定されて表示されますピップ10.0.0 2018年4月14日にリリース。 厳密に修正を言えば、していたdistlib 0.2.6自分でPIPにvendoredた、 PR4819最初ピップ10.0.0b2に登場2017年10月で、。

根本的な修正は、 distlibのコミット9285ccaにあるようです。 vsajipが2017年5月28日にここでコメントしたように、アプローチはHarald Nordgrenのアイデアに従います：単純なケースには単純なシバンを使用し続けます（OSはPosixではないか、パスが十分に短く、スペースがありません）が、単純でないケースには使用します代わりに/bin/sh execコマンド。これは、長いパスまたはスペースを含むパスを処理できます。

Mac OS X 10.11.6で簡単なテストを行い、スペースを含む長いパスで仮想envを作成してから、 pip3 installを呼び出しましたが、動作しているようです。 このバグで説明されているすべてがすべてのOSで修正されていることを完全にテストしていません。

Ubuntu 16.04.5 LTSを使用してpipを9.0.1から18.1（カレンダーベースのバージョンに切り替え）およびvirtualenvを15.0.1から16.0.0にアップグレードした後、問題はなくなったようです。

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

これで、すべてのpipコマンドは、ルートパスにスペースがあるvirtualenvで正しく機能します。

@JLDHと@gandieによって確認されたように、この問題は解決されました。 virtualenvのルートにスペースがある場合、pipとvirtualenvの最新バージョンが一緒に正しく機能します。

これを閉じます！ 根本的な修正@vsajipの作業に感謝します！

古いチケット：しかし、なぜですか

！/ usr / bin / env python？

@rirl 、クローズされた問題にコメントを残すことはあなたのアイデアの注目を集める可能性は低いと思います。 問題は解決策を与えられました。 このソリューションを使用した新しいvirtulenvは、別の方法で処理することで改善されると思われる場合は、新しい変更を提案しています。 新しいIssueを開くことを検討し、どのような変更が発生すると思われるかを述べ、その変更が新しいvirtualenvよりも優れている理由を説明します。