Virtualenv: pip実行可能ファイルでシバンの長さを超えました

私もこの問題を経験しています。

私も。

回避策をありがとう！

ラッパースクリプトは、実際にはsetuptools（sdistからインストールする場合）またはdistlib（wheelからインストールする場合）によって生成されることに注意してください。 したがって、この問題の修正は、これらのプロジェクトから実際に要求する必要があります。

しかし、それがOSの制限である場合、おそらく実行可能な修正は_ない_のでしょうか？ かつて、Perlは魔法の呪文を使ってスクリプトを実行したことを覚えているようです（グーグル少し...）はい、このようなもの（Python用に翻訳）

#!/bin/sh
eval 'exec /the/long/interpreter/path/to/python $0 ${1+"$@"}'

Pythonがeval-exec行を実行しようとしないように、いくつかの追加のものが必要になりますが、それは機能する可能性があります。

誰かがsetuptoolsとdistlibの機能リクエストとしてそのようなものを提案したいのなら、それは素晴らしいことです。

そのため、Python virtualenvが作成されるパスが長くなりすぎると、そのvirtualenvのpipを使用できなくなります。

この問題が発生するシステムでvirtualenvを実行すると、コマンドは、そのような長いパス名を持つディレクトリにあることは基本的にサポートされていないという警告（またはエラー）を出力する場合は、_本当に_素晴らしいでしょう。現時点でのデフォルト。

私もこれを打っています。 pwdへのパスが_非常に_長いJenkinsビルド内からpipを実行しているので、これは特に私にとって問題です。 興味深いことに、同じようにビルドされたビルドスレーブがいくつかあり（すべてBINPRM_BUF_SIZEが128に設定されており、pip、python、virtualenvのバージョンが同じです）、パスの長さが異なっていても、一部では発生していますが、他では発生していません。

@ b-longの提案が好きです。 virtualenvが現在のシステムで機能しないラッパーを作成する場合、完全に失敗しない場合でも、少なくともユーザーに警告を表示する必要があります。

virtualenvがこの状況をどのように検出できるかは明らかではありません。 Cヘッダーの値を正確に使用することはできません。また、この制限のあるシステム上にいることをどのように検出するかわかりません（Windowsにはありませんが、OSXですか？）

この問題は、virtualenvの問題ではなく、OSの制限としてクローズする傾向があります。

それが価値があるものについては、いくつかの考え...

1. ctypesはこれを行うことができますか？
2. 次のような単純なものはどうですか。

# on Linux, BINPRM_BUF_SIZE == 128, giving us a maximum shebang length of 127
# 2 bytes for #!, 11 bytes for '/bin/python' leaves us with 114
if sys.platform() == 'Linux' and len(home_dir) > 114:
    log.warn("bin/activate may not work your system, as the length of the shebang line will exceed 128 characters")

1. わからない、ごめんなさい。
2. 私はWindowsユーザーなので、意見はありません。 これが合理的だと思うなら、PRを上げて、Linuxの人々がどう思うか見てみることをお勧めします...

私が提案した変更は、他のユーザーにも喜ばれると思います。 コメントのためにこれを開いたままにして、PRを刺激することはできますか？ @jantmanと@pfmooreに感謝し

BINPRM_BUF_SIZEはカーネルヘッダーで定義されており、少数のカーネル関数でのみ使用されているようです。 これをプログラムで検出する方法はないと思います（ヘッダーを読み取ることはできませんが、実現可能性はほとんどありません）。

そうは言っても、これはすぐには変更されないと想定するのが妥当だと思います（ここに最大シバン長の概要がありexecve（2）のマニュアルページの「メモ」セクションにも明確に記載されており、「＃！実行可能シェルスクリプトの最初の行には最大127文字の行長が許可されています」と記載されています。

すべてのPOSIX準拠のオペレーティングシステムには何らかの制限があると思いますが、一部のオペレーティングシステム、特にBSDバリアントには、8,000文字以上の制限があるようです。

上記の提案のように単純にハードコーディングするのは合理的な解決策のように思えますが（プラットフォームがLinuxで、行が127文字より長い場合）、それは過度に粗雑で具体的で柔軟性がないように感じます。

virtualenvあまりオーバーヘッドを追加しない方法で、これをプログラムでテストする方法についてはまだ考えています（もちろん、これはvenvの作成時にのみテストする必要があるので、私は ' dある程度のオーバーヘッドが許容できると想定します）。

特定のパスが許容可能なシバンの長さであるかどうかをテストするための簡単な概念実証コードがいくつかありますが、ファイルをディスクに書き出してからファイルを実行して出力をキャプチャするため、かなり醜いです。 例と出力は次のとおりです： https ：

私はそれを夜と呼ぶ必要がありますが、私はこれに戻ってみようと思います。 他のLinuxユーザー、または同様の制限があるかどうかを確認できる他のOSのユーザーの意見をいただければ幸いです。

制限について推測するようなトリッキーなことをしようとする代わりに、機能テストのbashスクリプトを作成してみませんか？ Pythonが正しく呼び出されれば、すべてが桃色になります。そうでない場合はそうではありません。

繰り返しますが：

1. これを修正したい場合は、PRをsetuptoolsとdistlib送信してください。コードはvirtualenvまたはpipにありません。
2. 受け入れられるためには、コードはLinuxだけでなく、OSX、BSDなどを含むサポートされているすべてのプラットフォームで機能する必要があります（もちろん、他に方法がない場合は、プラットフォーム固有の条件が受け入れられます）

virtualenvの問題ではないため、この問題を解決します（長いディレクトリ名に完全なPythonインタープリターをインストールすることで同じ効果を得ることができます）。

この問題が発生しました。

PATHからPythonを使用してみませんか？ virtualenvは、すでにbindirを前に付けています。

#!/usr/bin/env python

virtualenvはすでにbindirを前に付けています

virtualenvをアクティブ化した場合のみ。 Virtualenvは、アクティベーションなしでの使用をサポートしています。

誰かがこれを混乱させると思うなら：

この問題の回避策は、pipを直接実行するのではなく、virtualenvのpythonインタープリターを実行し、実行するソースとしてpipスクリプトをpythonに渡すことです。

その代わりの手段pip install -r requirements.txt DO python -m pip install -r requirements.txt