Pip: デフォルトは--user

これは、pypaのインストール手順にとって何を意味しますか？

現在、ルートまたは管理者アクセスについての言及は脚注にあるため、手順は基本的に同じままです（ get-pipが自動的にデフォルトで--userに設定されていると仮定します）。 変更は、現在のユーザーにのみ適用されるインストールで終わることを説明することです。

--userの変更に関係なく、現在の手順では、debianなどの一部のディストリビューションがensurepipを無効にしていることを説明する必要があるため、pipを取得する方法としてそれを探しに行くべきではありません。

長期的には、彼らはそれを有効にしておくつもりだと確信しています。彼らはそれを行う方法を考えているだけです。

この問題は、pipがデフォルトでパッケージを管理する場所に関するものとして説明されていますが、（少なくとも私にとっては）ほとんど重要なのは、これが間接的にget-pipがデフォルトでpipを配置する場所に関するものであるということです。

これはaltinstallされたPythonとどのように相互作用しますか？
特にhttps://github.com/yyuu/pyenvのようなツールでインストールされるような

ユーザースキームは.local/lib/pythonX.Y/site-packagesなので、同じメジャー/マイナーバージョンで複数のpythonを管理している場合は、混乱する可能性があります。

実際のpythonを管理するそのようなツールの場合、pipをグローバルモードに固定することはそれらにとって意味があります。

redhat / fedoraバグトラッカーの関連する問題https://bugzilla.redhat.com/show_bug.cgi?id=662034#c10

Fedora / RedHatの場合、 PATH=$PATH:$HOME/.local/bin:$HOME/binはすでに/etc/skel/.bash_profileに含まれているようです。 これにより、少なくともbashユーザー（デフォルトのシェル）では、 --userでインストールされたものがデフォルトで表示されたままになります。 多分他のディストリビューションはすでにこれを持っていますか？

私が知っているWindowsについては特に違いはありません。 しかし、標準のPythonディレクトリを人々のPATHに追加したばかりであり、ユーザーごとのスクリプトディレクトリを作成するのが特に簡単になるとは思いません。技術的な問題もあるかもしれません。よくわかりません。 %LOCALAPPDATA%のようなユーザーレベルの環境変数をシステムレベルの%PATH%に入れることもできます:-(

私はこれを急ぐことに反対です。 ユーザーのインストールの経験が増え、最初に問題を解決できるようになるまで待つことをお勧めします。 それが鶏が先か卵が先かという問題であることは知っていますが、変化に突入することは助けになるとは思いません。

また、Windowsの帽子をかぶった状態で、sudoの不注意な使用が愚かなことをするのは悪いことだとまだ理解していないUnixユーザーにとって、それを難し​​くすることは、それほど正当な理由ではありません。 。

これは、システムPythonからpipを実行する場合にのみ適用されると思います。

Windowsでの別の点は、システム提供のPythonパッケージに付属している* nixのようなシステム提供のPythonがないことです:)

私もこれを急いでやりたくありません。 話し合いを始めたかっただけです。

これは、 sudo pip installと入力する人には実際には影響しません。これは、rootとして何かをインストールすると、デフォルトでシステムサイトパッケージに移動する必要があると思うからです。 これは、非特権ユーザーとして実行しているときに--userを使用するように人々をガイドするためのものです。 今あなたが得るものは、通常のユーザーとしてのpip installが許可エラーで爆破するということです。 そのメッセージを改善して爆破し、 --userを提案したとしても、それはまだ最高のUXではありません。

Fedoraの人の一人と話すとき、これを行う方法は、パーミッションチェックを実装することだと思います。 site-packagesディレクトリに書き込む権限がある場合、私は特権ユーザーであり、pipはグローバルPythonにインストールされます。そうでない場合、私は非特権ユーザーであり、 --userにインストールされます。

Windowsに関しては、Pythonをデフォルトで非特権ディレクトリにインストールするため、通常は問題を解決します。そのため、グローバルにインストールする場合、pipはUACをトリガーしません。 誰かが代わりにプログラムファイルにインストールするように変更した場合、UACはpipを実行したときにトリガーされます（これもOKです）。 インストーラーでユーザーごとのインストールを選択するとどうなるかわかりません。

Paulが指摘しているように、WindowsのPATHにはまだ_user_スクリプトディレクトリが含まれていません（グローバルディレクトリのみ）。したがって、これは間違いなく考慮する価値があります。

ただし、POSIX側に大きな障壁はありません。 このUXのアイデアはどのように聞こえますか：ホイールベースのインストールの場合、インストールターゲットディレクトリのアクセス許可を確認し、ユーザーに書き込みアクセス許可がない場合は、代わりに--userインストールを実行するかどうかを尋ねるプロンプトを表示しますか？ 新しい「--global」または「--system」フラグは、「no」の回答を強制します。

そして、将来のある時点で、プロンプトをスキップして、グローバルインストールの権限が適切でない場合は--userと単純に想定することができます。

プロンプト（--no-inputの場合を除く）は、おそらく遷移ステップに意味があります。 デフォルトでは、場所はユーザーがアクセス許可を持っている場所にあるため、アクセス許可を確認すると、Windowsでも機能するはずです。したがって、アクセスできるのは、明示的に指定されていないPythonを提供するシステム管理者を使用している場合のみです。彼らに許可を与える。

基本的に、これにより障害モードが大幅に改善されます。

sudoの不注意な使用をまだ解決していないUnixユーザーにとっては困難になります
愚かなことをするのは悪いことですが、それはそれほど正当な理由ではありません。

sudoとセキュリティは、実際には二次的な問題であるIMOです。
これは主に、システムpythonでのOSパッケージとpip間の競合を防ぐことです。
現在、Linuxユーザーはしばしば不可能な状況に置かれています。

1. OSマンデート： 'OS pkgmgrを使用します。 roque pipがインストールされたパッケージ（ get-pip 'd pipを含む）'でシステムを感染させないでください。
2. 現実：「OSパッケージ（pipを含む）が古すぎるため、一部のパッケージのアップグレードを取得するためだけに、ディストリビューションの実験的なリリースにアップグレードすることはできません。不正になります...」

もう1つの赤ちゃんのステップは、 get-pip.py --userが可能であることを文書化し（テストしたと仮定して）、PUGに--user virtualenv （およびwheel 、およびtwineも、virtualenvにない場合は）

FWIW、ディストリビューションベンダーも現状を問題と見なしており、コアOSコンポーネントに影響を与えることなく選択的なアップグレードを行うためのツールを改善するためのさまざまな方法を検討しています。 ただし、これらの取り組みは成熟のさまざまな段階にあり、エンドユーザー向けの一貫したクロスプラットフォームソリューションが必要なため、上流側から取り組む価値はあります。

Unix上のディストリビューションとの連携を支援するために物事を変更することに問題はありません。 WindowsではなくUnixでデフォルトで--userを使用できる場合は、それで問題ありません。 Unixでの悪い経験からWindowsでの悪い経験への切り替えは、良いトレードオフだとは思いません。 そして、私はまだWindowsの--userが最高の時間の準備ができていると確信していません。

Windowsでpip_is_ badを実行しているときにUACをトリガーすることは、実際には、昇格されたコンソールウィンドウ以外ではpipが実行されないことを意味するためです。 ピップユーザーが「OK」と言うことができる素晴らしいプロンプトを受け取るという意味ではありませんが、残念ながら、それがGUIアプリの動作方法にすぎません...

@pfmoore pip install何かをしていて、ディレクトリに書き込む権限がない場合、Windowsのユーザーエクスペリエンスはどうあるべきだと思いますか？

FWIW Windowsに応じて、これをオプションにするかどうかはまったく問題ありません。 「site-packagesフォルダーに書き込むためのアクセス許可がありますか」チェックのチェックでは、99％のインストールでそれが達成されないのではないかと思っています。また、-userにインストールすると、 site-packagesディレクトリへの書き込み権限がない場合のごく一部。

つまり、パーミッションを確認すると、プロポーザルがグローバルインストールをユーザーインストールに置き換えていない場合、パーミッションエラーを--userインストールに置き換えています。

この提案は、グローバルインストールをユーザーインストールに置き換えるものではありません
パーミッションエラーを--userinstallに置き換えています

わかりましたが、権限チェックのアイデア（＃1048）が最も簡単なことではないことを思い出してください

Wheelケースでは非常に簡単で、99.9％のケースをsdistsでカバーできます。これは、本当にファンキーなことを行うsetup.pyでのみ問題になるはずです。

何かをpipインストールし、ディレクトリに書き込む権限がない場合、Windowsのユーザーエクスペリエンスはどのようになると思いますか？

そうですね、Windowsではsite-packagesディレクトリに書き込めるのは非常にまれなので、質問が実際にどれほど関連性があるのか​​わかりません。 しかし、それが起こった場合、「システムサイトパッケージは書き込み可能ではありません- --userを使用するつもりでしたか？」というエラーが発生したと言えます。 賢明なアプローチになります。

実は、Unixでもそうだと思います。 書き込み可能性に応じて動作を切り替えるのは奇妙であり、書き込み可能なディレクトリで個人的に作成されたPythonに--userを使用することが正しいアプローチであるかどうかはわかりません（ただし、このような設定の経験はまったくありません。その意見を裏付けるものは何もありません）。

提案：上記のように--userを提案するエラーから始めます。 人々が--userをより一般的に使用し、それについてより多くの経験を積んだら、デフォルトを切り替えることを検討しましょう。

Paulが提案するアプローチは、大まかに私が考えていたものですが、エラーメッセージで解決するのではなく、yes / noプロンプトを使用します。 これらの2つのアプローチには長所と短所があります（主に、別のスクリプトから呼び出されたときにどのように失敗するかに関連しています）。

sys.localprefix（ここにpython-devが表示されます）のようなものをPythonに追加することは可能でしょうか？
Sys.localprefixはデフォルトでsys.prefixになります。 ディストリビューションは、プレフィックスを定義するのと同じ方法で定義できます（たとえば、prefix = '/ usr'、localprefix = '/ usr / local'）。 Pipとeasy_installは、sudoとして使用する場合、インストール先の場所としてsys.localprefixを使用します。十分な権限がない場合は、-userにフォールバックします。

私たちはFedora17の「geminstall」でこのようなことをしました、そしてRuby開発者はそれについて一般的に非常に満足していたので、私は共有したいと思いました：

• 「geminstallfoo」は、uid！= 0の場合、「foo」を〜/ somedirにインストールします。
• 「geminstallfoo」は、uid == 0の場合、「foo」を/ usr / local / somedirにインストールします。
• 「yuminstallrubygem-foo」は、RPMパッケージの「foo」を/ usr / somedirにインストールします

ユーザー権限に基づいてインストールディレクトリを選択することは、人々を非常に混乱させると思います。 「pipinstallfoo」は、root以外のすべてのユーザーに対して同じように機能するはずです。 大多数のユーザーを検討する場合、ユーザーは自宅に「pip install」を実行し、システム全体のディレクトリに「sudopipinstall」を実行することをお勧めします。 したがって、上記のようにuidに基づいてこれを行うのが最善のアプローチだと思います。rootではないがシステム全体のディレクトリにインストールしたいユーザーには、常に--targetオプションがあります。

@bkabrdaは、$ PATHにスクリプトを追加することを心配しない限り、簡単に選択できます。 そこで何をしましたか？

@dstufftが指摘しているように@Ivozは、FedoraがすでにPATHに$ HOME / .local / binを持っているので、すべてが箱から出して動作しました（スクリプトと言えば）。

Slavekの提案は、POSIXシステムについては私には良いと思います。 コンテナ内で実行されているものは、完全にコンテナの外部からのものであるにもかかわらず、uid 0であると考えるように指示できるため、コンテナでもうまく機能するはずです。

Windowsの場合、正しい答えが何であるかはわかりません。 システムパッケージマネージャーとの議論に入るのとまったく同じ問題はありませんが、ある程度は存在し（pipインストールとMSIインストーラー）、Python 3.4でも、インストーラーのオプションのPATHという追加の複雑さがあります変更を加えると、グローバルScriptsディレクトリのみが追加され、ユーザーごとのディレクトリは追加されません。

また、Windowsには、Pythonがデフォルトの場所（制御されていない）にインストールされているか、プログラムファイルにインストールされているか（変更を加えるためにUAC特権の昇格が必要）に基づいて奇妙なことがあります。

@rkuskaによって提案された「localprefix」のアイデアは、私には素晴らしく、シンプルで簡単に見えます。 また、 @ bkabrdaが提案するアプローチ、特にpython3.xをデフォルトのpythonにするArchのようなディストリビューションが本当に気に入っています。

もう1つの注意点は、ArchがDebianと同じように3.4.0リリースでensurepipを無効にしていることです（主に、最新バージョンのsetuptoolsとpipを提供したいのですが、バンドルされたバージョンは古くから古い可能性があります）。そのためのヒント。

@lvoz
Archの場合、$ HOMEの下のPATHにパスを追加しませんでしたが、それでも問題ないと思います。 ユーザーに追加するように指示するRubyのwikiエントリがすでにあります。

ArchとDebianの開発者は、単に無効にするのではなく、Slavekがパッチに取り組んで、確実にシステムバージョンからホイールを再構築し、それを仮想環境にインストールできるようにするとよいでしょう。

参考までに、FedoraのCoprビルドシステムでPython 3.4 RPMビルドをすでに実行しています（テスト中です。何も壊したくない場合はインストールすることをお勧めしません）。 私たちがこれにどのように取り組んでいるかについてもっと知りたい場合は、コードなどを見てください。debian-pythonMLでのBarry Warsaw [2]との私の議論を参照してください。
（私たちのパッチは、アップストリームで提案する前にまだある程度の愛情が必要ですが、ダウンストリームのATMではすべて問題なく機能します）

[1] http://copr-fe.cloud.fedoraproject.org/coprs/bkabrda/python-3.4/
[2] https://lists.debian.org/debian-python/2014/03/msg00046.html

申し訳ありませんが、AFAIK Archはwheelをサポートしていません。また、ensurepipがパッケージマネージャーを呼び出すようにする必要もありません（ただし、このアプローチが間違っていると理解している場合は修正してください）。

surepipの場合、ensurepipを使用してpipをインストールしないようにユーザーに警告することをお勧めします。これは、今のところ私が考えることができる最も多くのことです。

私たちのensurepipはパッケージマネージャーを決して呼び出さないでしょう。 つまり、Fedoraのensurepipは、システムにパッケージ化されたsetuptoolsとpipに依存して常に存在し（python3パッケージはそれらに依存し、依存関係ループを作成しますが、それを処理できます）、ユーザーが新しいvirtualenvを作成すると、再パックします。システムsetuptoolsを使用してホイールに接続し、新しいvirtualenvにインストールします。
私たちは少し話題から外れ始めているので、私たちはこの議論をどこか別の場所で続けるべきだと思います...

@felixonmars Arch venvではDebianと同じように壊れているということですか？

OK、説明ありがとうございます、私はアイデアを得たと思います。 私に何ができるかを見て、これについてdebian-pythonをフォローアップします。

@dstufftはい、システムバージョンの代わりにバンドルバージョンがインストールされました。

@bkabrdaこれにより、システムPythonでpipを呼び出す場合の問題が解決されるため、その場合は特別な場合のvirtualenv / venvを使用する必要があります（これは世界の終わりではありません）。 ただし、 https：//github.com/yyuu/pyenv （実際にPythonを実行する方法）など、ユーザーがホームディレクトリにインストールしたものも含め、すべてのPythonがシステムPythonであると想定していることも意味します。 よくわからないので、許可チェックを考えました。

@dstufftが言ったことと同じように、 pyenvのようなツールを使用して非ルートpythonをジャグリングする場合、 rootがグローバルインストール（「グローバル」の場合）を実行するためのキーになるのはかなり奇妙です。 ！= "システム"）

Fedora17の「geminstall」でこのようなことをしました

つまり、fedora 17のgemのrpmはこれをディストリビューションハックとして持っているのですか、それともgem自体がこのロジックを持っているのですか？

1つの考えは、pipは、pipをパッケージ化するディストリビューションによって、またはユーザーがpipをシステム管理のPythonにインストールしていることを知っているときにオンにできる「システムフレンドリーモード」を提供する必要があるということです。 それ以外の場合、pipは通常のデフォルトのグローバルロジックを実行します。

ああ@felixonmarshttps：//projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD？h = packages / pythonを見ただけなら、 --without-ensurepipを呼び出すだけで問題ありません。 これにより、venvモジュールのensurepipモジュールはそのまま残ります。 Ubuntu（Debian？）が現在実施しているパッチは、ensurepipパッケージ自体で実際にrm -rfを呼び出し、venv内で呼び出すことができないようにします。

ユーザーインストールのデフォルト設定は、2年前、またはおそらくもっと前の誰かによって提案されたと思いますが、スレッドはさまざまな方向に進み、実りはありませんでした。 主な障害は後方互換IIRCでしたが、最近では、sysadminsとpipユーザーは、良くも悪くも、virtualenv / pip / setuptoolsの更新に注意するために使用される可能性があります。 その議論がdistutils-sigまたはpypa-devで起こったかどうかは覚えていません。

それはcatalog-sigでした： https ：//mail.python.org/pipermail/catalog-sig/2013-February/004773.html

@dstufftああ、なるほど...しかし、システムごとにパッケージがインストールされているのに、バンドルされた（おそらく古い）バージョンをインストールするのはまだ間違っていると感じています:)

@felixonmars問題は、システムパッケージをvirtualenv afaikにインストールできないことです：）（システムパッケージとvirtualenv内で必要なものに異なる懸念がある場合でも）

@dstufftここで、Slavekのリホイールが始まりますが、それは少し話題から外れています:)

はい、 https： //lists.fedoraproject.org/pipermail/python-devel/2014-March/000583.htmlの最後のビットを確認してください:(

@dstufftありがとう！

Archでpipをアンバンドルしなかったので、それは問題ではなく、rewheelは使用可能なホイールを生成するはずなので、そこで議論を続けるべきかどうかはわかりません:)

@dstufft確かに、virtualenvと、場合によってはpyenvを特殊化する必要がありますが、これは醜いようです。 私はpyenvにあまり精通していないことを認めなければならないので、今のところそのための「適切な」解決策を考えることはできません。 私はそれを詳しく見て、何かを考えようとします。

Fedoraの「 geminstall 」の@qwcode、これはダウンストリームパッチです。 TBH FedoraのRubygemsには長い間触れていませんでしたが、最後にチェックしたときはダウンストリームのみでした。

この問題へのリンクをPythonの関連バグに投稿しました[1]。 この議論をPythonコアに移し、 pipだけでなく、 easy_installとpython setup.py installのローカルインストール用に構成可能な場所を設定したいと思います。その後、pipは（例）@bkabrdaが述べたように、 uid==0の場合はsys.localprefix dir、$＃$ uid!=0の場合はuserdirにインストールします。

とりあえず、デフォルトでユーザーdirにpipをインストールしても問題ありません。

[1] http://bugs.python.org/issue1298835

Nickが指摘したように、私は議論をissue1298835からpypa-devに移しました[1]。
[1] https://groups.google.com/forum/#!topic/pypa -dev / r6qsAmJl9t0

デフォルトは--user

良いアイデア！

pip install fooにはファイルのアクセス許可がないため、エラーがスローされます。 これにより、代わりにsudo pip install fooを実行し、システムPythonにグローバルにインストールします。

それより悪いです。 多くの人（大学のコンピュータネットワークのユーザーなど）はsudo特権を持っていません。 pipがパーミッションエラーで失敗すると、次のいずれかになります。

1. 管理者に電子メールを送信し、パッケージをインストールするように依頼します。 それは誰にとっても遅くて退屈です。
2. 諦めてパッケージなしでやりなさい。

彼らが特に経験豊富または十分な知識を持っている場合にのみ、彼らはpip install --userを試します。

'default to --user'に反対することになった場合は、混乱の少ない代替案を検討する必要があります。

1. --userへのフォールバック（perimissionsエラーが原因でインストールが失敗した場合）
2. （ペリミッションエラーが原因でインストールが失敗した場合）、ユーザーに（大きな親しみやすい文字で）-userを試すように促します

私は実際にすべてのインストールで--userをしばらく使用していますが、一般的に人々はこのオプションに気づいていません。 オプションを忘れるたびに権限エラーが表示されるのは煩わしいことに同意します。 ただし、ユーザーのインストールはcondaと互換性がないことに気付きました（conda / conda＃448）。

3.5がデフォルトでプログラムファイルにインストールされるようになった今、人々はWindowsでこれに遭遇することがはるかに多いので、これを復活させたいと思います（変更するには管理者権限が必要です）。

インストールに最適な「パーミッションエラーで--userにフォールバック」オプションが好きです。アンインストールでは「デフォルトで--userにフォールバックし、システムにフォールバック」し、 --systemまたは--system-onlyオプションを追加します。フォールバックを防ぐため。 管理者権限で意図的にpipを実行しているユーザーは、期待どおりにシステムをインストールします。現在、権限のないユーザーはエラーが発生するため、ここでバックコンパットの問題は発生しないと思います。

私の目的は、情報のないユーザーがエラーなしpip install spam; python -c "import spam"を実行できるようにすることです（ただし、 --userで再試行すると警告が表示される可能性があります）。

特に最近＃2403と＃2401がオープンして以来、私はこれについて考えていました。それにより、 sudo pip installの使用と、それがアクセス許可の問題以外のシステムを壊す可能性があることを考えさせられました。

この目的のために、より良い最終目標は、 --userがデフォルトであり、魔法の権限チェックがなく、 --global 、 --systemのような新しいフラグを追加することだけではないかと思います。または--no-userは、以前の動作を復元します。 設置方法や設置場所に関係なく同じ動作をするので、説明しやすいです。

さて、それが私たちの行きたい方法であると判断した場合でも、現在の場所からどのようにしてそのポイントに到達するかという問題があります。 明らかに、どの時点でもデフォルトを切り替えると、かなり大きな重大な変更になるため、かなり長いリードタイムが必要になります。 そのようにすることが最善の方法であると判断した場合は、引き続き--userオプションを維持し、$ --globalのような新しいオプションを追加してから、他のオプションが構成されていない場合は、前述のパーミッションチェックマジックを実行します。マジックが--globalの動作を使用することを決定した場合は、非常に大きな非推奨の警告が表示されます。 この非推奨の警告は、動作にかなり大きな変化が生じるため、これまでに発行した他の非推奨よりもずっと長く続きます。 また、魔法のフォールバックをオフにして将来の動作を実装するオプションを追加して、人々が今日その動作を取得できるようにしたいと思います。

もう1つの重要な質問は、インストール先のPythonでユーザーサイトが有効になっていないことを検出した場合の対処方法です。 この場合、 --userはエラーであり、これらのPythonの場合は、デフォルトの--globalにフォールバックするだけです。 これは私が自動的に信じるvirtualenv / venvをカバーし、完全にコンパイルされたPythonを使用して「より重い」重みの分離された環境が必要な場合は、 site.pyにパッチを適用して、 ENABLE_USER_SITEをFalseに設定できます。ファイルの先頭にある

+1、そして私は--systemに投票します。

私は注意します、そしてあなたがこれを気に入ると確信しています、Ubuntuのデフォルトは変更されました：

https://launchpad.net/ubuntu/+source/python-pip/1.5.6-4ubuntu1

2015年2月9日、午後4時41分、ドナルドスタッフは次のように書いています。

この目的のために、より良い最終目標は、 --userが
デフォルトでは、魔法の権限チェックは行われず、 --globalのような新しいフラグが追加されます。
--system 、または--no-userは、以前の動作を復元します。 これ
どんなに同じ振る舞いをするので、人に説明しやすいです
物事がどのように/どこにインストールされるか。

--systemは、実際には一部のPythonにのみ適用されるため、間違っていると思います。 以下には適用されません。

• Windows上のPython
• pyenvはPythonをインストールしました
• CondaはPythonをインストールしました
• NixがインストールしたPython
• カスタムコンパイルされたPython。

これは、Pythonがシステムによって出荷される* nixシステムにのみ適用されます。 --globalがその旗のはるかに良い名前だと思います。

そしてFML、なぜDebian / Ubuntuは、予想されるユースケースを破るランダムなパッチを絶えず追加する必要があると感じているのですか？

それで、Ubuntuパッチが元に戻された場合、これがここで修正されるまでのタイムラインは何ですか？ 一週間/ 1ヶ月/ 3ヶ月/ 6ヶ月/ 1年...？

それはあなたが固定によって何を意味するかに依存します。

しばらく前に私が2つの投稿をしたというアイデアを使用していると仮定すると（他のpip開発者からの承認が必要です）、次のことが当てはまる移行計画をすぐに得ることができます。

• --userが渡されると、ユーザーサイトパッケージに_常に_インストールされます。
• --global （またはその他）が渡されると、グローバルサイトパッケージに_常に_インストールされます。
• どちらも渡されない場合、フォールバックメソッドを実装します。
  
  
  
  • 仮想環境にいるかどうかを検出し、仮想環境にある場合は、 --globalが渡されたかのように動作します。
  
  
  • ユーザーsite-packagesが無効になっているかどうかを検出し、無効になっている場合は、 --globalが渡されたかのように動作します。
  
  
  • 有効なユーザーにsys.pathへの書き込み権限がないかどうか、および--userが渡されたかのように動作しないかどうかを検出します。
  
  
  • 最後に、他のすべての検出方法が失敗した場合は、 --globalが渡されたかのように動作し、将来のある時点でこの動作が変更され、代わりに--userにインストールされることを示す非推奨の警告を出力します。
  
  

これにより、誰かがシステムPythonにsudo pip install fooを実行するのを止めることはできませんが、ある時点でこれは--userを意味し、明示的に--globalの使用を開始するように指示する警告が出力されます。

• --userが渡されると、ユーザーサイトパッケージに_常に_インストールされます。
• --global （またはその他）が渡されると、グローバルサイトパッケージに_常に_インストールされます。
• どちらのオプションも渡されない場合、次のようなフォールバックメソッドを実装します。
  
  
  
  • 仮想環境にいるかどうかを検出し、仮想環境にある場合は、 --globalが渡されたかのように動作します。
  
  
  • ユーザーsite-packagesが無効になっているかどうかを検出し、無効になっている場合は、 --globalが渡されたかのように動作します。
  
  
  • 最後に、デフォルトとして--userを使用します。
  
  

ただし、最初の動作から2番目の動作への移行には、かなり長いタイムラインが必要になります。 これは非常に大きな変更であり、ソフトウェア（salt、chef、puppetなど）またはデプロイメントスクリプト（世界中の何千ものプロジェクトに焼き付けられたカスタムの1回限りのFabricスクリプトなど）の問題を解決します。 sudo pip install <foo>はグローバルPythonにインストールされます。 人々が警告を見るのに長いリードタイムを与え、実際にその動作が必要な場合は、明示的な--globalフラグを渡すようにソフトウェアとスクリプトを変更する必要があります。

ドナルドの提案した計画は良いものだと思いますが、pipチームがそのアプローチを採用することを決定した場合は、CPythonに3.5リリースブロッカーの問題を提出して、ユーザーごとのスクリプトディレクトリをグローバルとともにWindowsのパスに追加する必要があります一。 3.5がデフォルトでプログラムファイルへのインストールへの切り替えとともにそれを追加した場合、管理者権限なしでインストールするという望ましい動作が「正常に機能」し続けるはずです。

pip構成ファイルを介してデフォルトのインストール場所を変更できることも便利であり、デフォルトがまだ変更されていない場合でも、ユーザーが自分のシステムで「デフォルトでユーザーごと」にオプトインできるようにします。 （例：「default-install = user」と「default-install = global」）

@dstufft ：必要に応じて、ubuntuのバグで説明されているように、提案を実装するための手を差し伸べることができてうれしいです。 トランクでその動作が得られたら、もちろんバックポートして現在のubuntuパッチをこれに置き換えます。

ヘルプが必要な場合は、私に投稿してください。

私は@dstufftの計画で+1です。 記載されている理由から、名前として--globalを使用します。 私たちはもう十分長い間柵に座っていました、それのために行きましょう。

Python3.5がユーザーサイトディレクトリをWindowsのPATHに追加するという@ncoghlanの提案のO'nと+1。 この移行のためのさらなる障害を避けましょう。

私は@dstufftの計画では+1、 --globalでは+1ですが、 sudo pip install fooに--global $が必要かどうかはまだ疑問です。 実際、rootがユーザーサイトパッケージを持つ必要はありますか？ 特別な場合のrootで、デフォルトでサイトパッケージをオフにすることはできますか？ （これにより、 sudo pip install fooが現在と同じように機能します）

現在の状態でrootに--userを使用している人を見たことがありませんが、誰かが実際にそのようなユースケースを知っている場合は、知りたいと思います。

私が思いついたのは、ユーザーサイトディレクトリが複数のバージョンのPythonがインストールされている場合にどのように機能するかということです。

Python 2.7および3.4​​（Python 3.4ではデフォルトのPython）でpip install pytest --userを実行した場合、 py.testコマンドはどのバージョンで実行されますか？ 2つのインストールが互いに上書きするのではないかと疑っています。そのため、「最後の1つが勝つ」状況であり、これは良くありません。 また、「最後の1つが勝つ」で、3.4バージョンの後に2.7バージョンをインストールした場合、3.4を再びデフォルトにするには、どうすれば修正できますか？

そして、アンインストールはどうですか？ 次のシナリオを検討してください（メインのラップトップを壊す危険を冒したくない場合は、クリーンなマシンをセットアップする必要があるため、テストされていません）。

    C:\Apps\Python34\python.exe -m pip install pytest --user
    C:\Apps\Python27\python.exe -m pip install pytest --user
    C:\Apps\Python34\python.exe -m pip uninstall -y pytest

まず、2番目のコマンドが既存のファイルを上書きしているという警告を発行しなかったのはなぜですか？ それともそれでしょうか？ それがあったかどうかにかかわらず、私は何をすべきかについてのオプションがありますか？

次に、 py.test.exe RECORDファイルの値と一致しないため、アンインストールが失敗しませんか？ 失敗した場合、どのようにアンインストールしますか？ 失敗しない場合、Python 2.7のpytestのコピーを（exeを削除することで）壊しますか？

そして最後に（今のところ！）ユーザースクリプトディレクトリはPATHのシステムスクリプトディレクトリの前または後に移動しますか？ IMO、それは後にする必要があります。そうしないと、ユーザーから「デフォルトのPython」として要求されなかったPythonでのパッケージのユーザーインストールが、「デフォルト」のPythonのシステムサイトパッケージにインストールされた同じパッケージをオーバーライドする可能性があります。

うーん、この変更を行う前に解決する必要のある未解決の質問があるかもしれません...

共有Windowsユーザースクリプトディレクトリでの名前の衝突は、共有binディレクトリを使用するPOSIXシステムで処理されるのと同じ方法で処理されると思います。Python3は、インストールされたパッケージに非修飾スクリプト名をインストールしないため、非修飾名前はPython2バージョンを指します。

システムインストールまたはユーザーごとのインストールがデフォルトで優先されるかどうかについても同じことが言えます。システムディレクトリの後にユーザースクリプトディレクトリを配置します。

「Python3は、インストールされたパッケージの非修飾スクリプト名をインストールしません」-おそらく、pipとsetuptools（Python 3の下）はインストールされないということですか？ それがそれらのツールへの変更ですか？

ああ、そしてブレ。 私の筋肉の記憶は、デフォルトのPython（3.4）にインストールするために「pipinstallfoo」と入力するように100％トレーニングされています。 それは再訓練するのは地獄になるでしょう。

また、Windowsユーザーは、システムPythonがルールを作成するUnixユーザーとは異なり、「python」がPython 2または3のどちらを意味するかを選択できます（「これをデフォルトのPythonにする」および「PATHに追加」を使用）。 では、Python 3.5をデフォルトにしたいのであれば、なぜ「pip」（またはその他の修飾されていない名前）がそのバージョンを参照するべきではないのでしょうか。 Python 3.5のみがWindowsにインストールされているユーザーが、システムPythonが名前を付ける必要がある方法に関するUnixの問題のために、修飾されていない名前を使用できないのは奇妙に思えます。 （Unixの制約についての私の説明が不正確な場合はお詫びします-私はそこでの問題を本当に理解していません）。 複数のPythonバージョンをインストールする人には解決策が必要ですが、その解決策は、1つのバージョンしか必要としない大多数に影響を与えるべきではありません。

おそらく最も簡単な答えは、ユーザーサイトのパッケージディレクトリと同じように、ユーザースクリプトディレクトリをバージョン管理する必要があるということです。

ああ、そしてこの議論はここではなくpython-devで行われるべきですか？それはより一般的にはユーザーサイトディレクトリに関するものなのでしょうか？

python-devのWindowsユーザーごとのスクリプトディレクトリのPEP370設計ディスカッションを再開することは、確かに合理的です。 WindowsでのグローバルスクリプトのインストールがPythonバージョンによってスコープされているのは奇妙ですが、ユーザーごとのスクリプトのインストールはそうではありません。

これは、両方のレベル（グローバルまたはユーザーごと）で実行可能ファイルに共有名前空間を一貫して使用するPOSIXの状況とは対照的であるため、実行時の名前のシャドウイングではなく、インストール時に名前の競合が発生する可能性が高くなります。

並列インストールを処理するための一般的な解決策としては、「-m」スイッチが使用されます。これにより、別のスクリプトのシバン行の内容を推測するのではなく、呼び出しているPythonを常に把握できます。

-mについては理解しましたが、前回は物事を文書化する方法の文脈で取り上げられましたが、 pip install fooを（ -mを使用した）標準的なインストール方法として扱う必要があることが強く望まれました。

pipのマニュアルには、代替案すら言及されていません（Windowsでpip自体をアップグレードするために-mを使用する1つのケースを除く）。

stdlibパッケージのドキュメントで-mを使用して、pip呼び出しを処理することをお勧めします。
並列Pythonインストールの処理-これが唯一の呼び出しスタイルです
グローバルインストール、ユーザーインストール、仮想のすべてのプラットフォームで機能します
環境。

2015年2月9日午後7時58分、ncoghlanは次のように書いています。

pip構成ファイルを介してデフォルトのインストール場所を変更できる
人々が「デフォルトでユーザーごと」にオプトインできるようにすることも役立つかもしれません
デフォルトが変更されていない場合でも、独自のシステム
まだ。 （例：「default-install = user」と「default-install = global」）

私はこれが好き。 私たちが苦労していることの1つは、解決方法です
--userデフォルトに移行するためのアップストリームのより保守的なアプローチ。
ピップシステムを安全にし、他のシステムと一貫性を保つという競合する目標
ツール。 例えば

https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1419695
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725848

デフォルトを選択するためのシステム全体の構成ファイルがある場合は、
少なくとも関係するすべての機械は同一であり、ディストリビューションは同一ではありません
醜いデルタを運ぶ必要があります。 私たちがしなければならないのは、
設定ファイルとそれをユーザーに文書化します。 原因となった問題は
私たちが処理しますが、少なくとも説明するのは簡単でしょう。

Debuntuは現在サイト全体のpip.confファイルをインストールしているとは思いません（
再確認する）。

https://pip.pypa.io/en/latest/user_guide.html#configuration

1つの複雑さ：Python2とPython3に異なるpipスクリプトをインストールします。
したがって、バージョンごとに個別の構成ファイルが必要になると思います。
Python、たとえば/etc/{xdg/pip/}/pip{2,3}.confなど。

2015年2月10日午前1時24分、ポール・ムーアは次のように書いています。

私が思いついたのは、ユーザーサイトディレクトリがどのように機能するかということです。
Pythonの複数のバージョンがインストールされていますか？

Debian / Ubuntu（多分すべての* nixes？）では、衝突はありません。
ライブラリは〜/ .local / lib / pythonX.Y / site-packagesにインストールされます

ただし、〜/ .local / binで衝突が発生します。 を含むパッケージのインストール
pip install --user fooとpip3 install --user fooを使用するスクリプト 'foo'は
〜/ .local / bin / fooスクリプトを壊してしまいます。

この変更の欠点の1つは、Fedoraがデフォルトで~/.local/binを$PATHに追加する唯一のダウンストリームディストリビューションだと思うことです（これは/ usr / binと/ usr / local / binの前に配置する必要がありますユーザーサイトパッケージがサイトパッケージの前に来るように）。 理想的には、ダウンストリームは、 ~/.local/binがデフォルトで$PATHになるように、システムを変更できるようになります。

2015年2月10日午前7時24分、DonaldStufftは次のように書いています。

この変更の欠点の1つは、Fedoraが唯一のダウンストリームだと思うことです。
デフォルト$PATH ~/.local/binを追加するディストリビューション（
ユーザーサイトパッケージと同じように、/ usr / binと/ usr / local / binの前
サイトパッケージの前）。 理想的には、ダウンストリームはそれらを変更できるようになります
~/.local/binがデフォルトで$PATHにあるようにシステム。

はい、でもそれについては別の決定を下すことができます。 （というより、下流
ディストリビューションはそれを行うことができます。）

（そして、ユーザーと同じように/ usr / binと/ usr / local / binの前に来る必要があります
サイトパッケージはサイトパッケージの前にあります）

うーん、 @ ncoghlanは正反対のことを言った、それは（Windowsでは、特に
コンテキスト）ユーザースクリプトディレクトリは、システムディレクトリの_後_である必要があります。 どれの
ユーザースクリプトディレクトリがバージョン管理されていない限り、私は同意します。 もし
バージョン管理されているので、あまり心配していません。 しかし、それはおそらくその事実を反映しています
Windowsユーザーは、バージョン管理されていないスクリプトが衝突したり、
Unixユーザーのやり方であるpip2 / pip3のような怪物;-)

ああ、スクリプトの混乱はもっと一般的な問題であり、実際には--userとは正確には関係ありません。 同じ問題は、Windows --globalのインストールを除いてどこにでも存在します。 その問題の解決策は、この問題とは別に解決すべき二次的な懸念/問題だと思います。

だから現在の考え：

• 先ほど投稿した一般的な考え方については合意があると思いますので、そういうことで進めていきたいと思います。
• --globalフラグを使用します。
• --userにインストールしていて、 ~/.local/binが$PATHにない場合は、何らかの警告が必要になる可能性があります。
• フォールバック動作を本質的に無効にし、 --globalまたは--userのいずれかにハードコードする、ある種のdefault-installオプションが必要になります。
• pip 6.0の時点で、 /etc/にマシン固有の構成ファイルがありますが、これらはpipを実行しているPythonのバージョンに固有のものではありません。 これは、多少は異なりますが、優れた機能だと思います（また、スクリプトの混乱を解決することと密接に関連している可能性があります）。

まだ1つの大きな未解決の質問があります。誰かがsudo pip install fooを実行した場合、または誰かがsite-packagesディレクトリに書き込む権限を持っている場合、長期的にはどうなりたいですか？

私が考えることができるオプションは次のとおりです。

1. --globalにインストールします。 これは最も下位互換性のあるオプションであり、ユーザーが入力したときに期待するものを表している可能性があります。 ただし、グローバルPythonを（サイレントに）混乱させるという欠点があります。これは、多くのシステムでシステムの破損を引き起こす可能性があります。
2. --userにインストールすると、壊れたシステムから保護されます（私は思いますか？）が、rootユーザーが/root/.local/をインストールすることを期待する人はいないと思います。
3. エラーを出して、ユーザーに--userまたは--globalのいずれかを手動で選択するように要求します。
4. 最初の2つのオプションのいずれかを選択しますが、ディストリビューションが/etc/で入力できるスイッチを提供して、3番目のオプションを有効にします。

4番目のオプションが最適かもしれませんが、すべてのプラットフォーム/シナリオで同じように機能し、私と同じようにすべてのプラットフォームで意味のあるソリューションが得られる場合は、最初に他のオプションの1つを選択する必要があると思います。可能であれば、プラットフォーム間で一貫した動作をすることをお勧めします。

「書き込み権限があります」は、WindowsのすべてのユーザーがPython 3.5より前のユーザー、Condaを使用しているユーザー、またはpyenvを使用しているユーザーのシナリオになるため、3番目のオプションはおそらく悪いオプションだと思います。 エラーアウトは、これらすべての場合に行うのは間違っているように思われ、ユーザーが起動するのが非常に不便です。

ですから、1から2の間で、人々が（概念的に） sudo pip install --global fooを行うのは、どれほど悪い習慣であると私たちが考えるかということになります。 Windows、Conda、pyenvなどでは、その答えは「悪い習慣ではないと思います」と感じています。 * nixでは、おそらく答えは「ユーザーはシステムに対してやりたいことを実行できるようにする必要がありますが、「悪い」ことからユーザーを遠ざけるためのレールを提供する必要がある」と感じています。

それで、それについてもっと考えて、私は私たちが行くための正しいオプションである最初のオプションで行かなければならないと思います。 これにより、下位互換性の問題が多かれ少なかれ解決されます。これは、グローバルディレクトリにインストールする許可なしにpip install fooと入力すると、代わりに--userにインストールするという動作が実際に変更されるためです。エラーが発生します。 その場合、ピップがエラーを発生させることに依存している人が実際にそこにいる可能性は低いと思います。 また、rootユーザーとしてのpip install --userは、誰もが期待または望んでいるものではない可能性が高く、実際にはユーザーのための足がかりになっていると思います。

したがって、更新された提案は次のようになります。

• --userが渡されると、常にユーザーサイトパッケージにインストールされます。
• --globalが渡されると、常にグローバルサイトパッケージにインストールされます。
• どちらも渡されない場合、フォールバックメソッドを実装します。
  
  
  
  1. 仮想環境にいるかどうかを検出し、仮想環境にある場合は、 --globalが渡されたかのように動作します。
  
  
  2. ユーザーsite-packagesが無効になっているかどうかを検出し、無効になっている場合は、 --globalが渡されたかのように動作します。
  
  
  3. default-installを調べ、それが存在する場合は、それに基づいて--userまたは-globalを使用します。
  
  
  4. 有効なユーザーがグローバルサイトパッケージへの書き込み権限を持っていないかどうか、および--userが渡されたかのように動作しないかどうかを検出します。
  
  
  5. 最後に、他のすべての検出方法が失敗した場合は、 --globalが渡されたかのように動作します。
  
  

これは非推奨期間がないことを意味し、 --userまたは--globalがない場合は、実行しているPythonの機能に基づいて最善の推測を試みることが期待されます。 、有効なユーザー、および構成済みのデフォルトのインストール方法。

（そして、ユーザーと同じように/ usr / binと/ usr / local / binの前に来る必要があります
サイトパッケージはサイトパッケージの前にあります）

うーん、 @ ncoghlanは正反対のことを言った、それは（Windowsでは、特に
コンテキスト）ユーザースクリプトディレクトリは、システムディレクトリの_後_である必要があります。 どれの
ユーザースクリプトディレクトリがバージョン管理されていない限り、私は同意します。 もし
バージョン管理されているので、あまり心配していません。 しかし、それはおそらくその事実を反映しています
Windowsユーザーは、バージョン管理されていないスクリプトが衝突したり、
Unixユーザーのやり方であるpip2 / pip3のような怪物;-)

スクリプト名がぶつかるという観点からも考えていません。 $PATH変数がsys.pathとは異なる動作をするのは、まったく間違っていると思います。 私の知る限り、 sys.pathの順序は、stdlib>ユーザーサイトパッケージ>グローバルサイトパッケージです。 some-scriptの順序がグローバルbindir>ユーザーbindirであり、 python -m some-scriptがユーザーサイトパッケージ>グローバルサイトパッケージである場合、非常に混乱すると思います。

スクリプトディレクトリ（およびバージョン管理されたディレクトリとバージョン管理されていないディレクトリ）に問題がある場合は、その問題を修正する必要があると思いますが、 sys.pathと一致する以外の何かのように感じるので、それらの順序とはあまり関係がありません。

良い点として、$ PATHがsys.pathの後に続き、（Windows用語では）C：PythonXYScriptsの前にC：PythonXYScriptsが付いていると想定（および推奨）する必要があります。 python-devスレッドで注意します。

ドナルドの最新の提案は私には良さそうです（私の元の提案に加えて、私が省略したすべての重要な詳細と同じです:)）。 「もっと考えて…」という段落にも100％同意します。

WindowsでPATHを設定することに関しては、それはほとんど不可能になるでしょう。 システム全体のインストーラーは、システム全体の環境変数のみを構成でき、拡張を含めることはできないため、ユーザーごとに異なるパスを設定することはできません。 （ユーザーごとのインストーラーで実行できますが、その場合--globalが成功するため、必要ありません。）

また、WindowsのPATH処理が壊れているため、システム全体の設定はユーザーごとの設定よりも常に優れています。 これは、バージョン管理されていないスクリプトにpy.exeランチャーを使用することについて、しばらく前に（python-dev、IIRCで）私の半分の提案につながりました。そのため、 pip.exeは、常に最新のシステムまたはユーザーPythonに移動します。それをインストールしたもの、および（例えば） pip.exe -3.5は特定のバージョンの選択を可能にします。

これを実際に機能させる唯一の方法は、Pythonインストーラーがバッチファイルのインストールを開始して、要求に応じてPATHを構成することです（バッチファイルを実行するショートカットの場合もあります）。 したがって、ユーザーが最初に入力するのはactivate-py35で、次にPATHが3.5用に正しく構成されます。 vcvarsall.batの状況に陥りたくないので、私はこれに非常に悩まされていますが、同時に、現在インストール場所について推測したり、レジストリを調べたりするスクリプトには最適です。それを見つけるために。

バッチファイルを実行するショートカットかもしれません

私の考えでは、これは「Python 3.5（32ビット）コマンドプロンプト」のショートカットです。 Visual Studioユーザーは、並列を認識する必要があります。

Windowsについては、そのすべての意味を完全に理解するのに十分な知識はありませんが、スクリプトfoo pip install fooがすぐに実行できない状況に戻るのはかなり気分が悪いです。コマンドラインでfooとして実行されます。 --userにインストールしていて、それがデフォルトでパス上にない場合、それは私にとってかなり大きな回帰のように感じます。

バージョン管理されていないスクリプトにpy.exeを使用することが実際にどのように機能するか、そしてそれが実際に問題を解決するかどうかを正確に理解しているかどうかはわかりません。 私は今日のようにスクリプトを作成することに個人的に縛られているわけではないので、それが機能する場合はおそらくそれができると思いますが、+ 1を与える前に、その影響をよりよく理解する必要があります。

WindowsでPATHを設定することに関しては、それはほとんど不可能になるでしょう。 システム全体のインストーラーは、システム全体の環境変数のみを構成でき、拡張を含めることはできないため、ユーザーごとに異なるパスを設定することはできません。

ああ、うん。 私はそれを忘れていました。

バッチファイルを実行するショートカットかもしれません
私の考えでは、これは「Python 3.5（32ビット）コマンドプロンプト」のショートカットです。 Visual Studioユーザーは、並列を認識する必要があります。

...これは、すべてをPowershellにデフォルト設定する私たちにとっては恐ろしいことです。

しかし、スクリプトfooをインストールするpip installfooをコマンドラインですぐにfooとして実行できない状況に戻すのはかなり気分が悪いです。

同意しました。 これは悪いリグレッションであり、対処する必要があります。 誰かが方法を考えてくれることを願っています:-)

バージョン管理されていないスクリプトにpy.exeを使用すると、実際にどのように機能するかを正確に理解できません。

ポイント（ py.exeにある程度関連しているだけです）は、現在のように特定のハードコードされたPythonインタープリターを呼び出すのではなく、exeラッパーが「何に基づいてインタープリターを動的に選択する必要があるか」ということです。どういうわけかデフォルトです」（レジストリ、 py.exe iniファイル、Python％PATH％が提供するものは何でも...）。 ただし、バージョン管理されたuser-scriptsディレクトリが必要であるため（ファイルが相互に上書きされたり、パッケージがインストールされていないインタープリターで実行されているファイルを回避したりするため）、どのように役立つかはわかりません。 ％PATH％の正しい位置にそれを置くことができません。

...これは、すべてをPowershellにデフォルト設定する私たちにとっては恐ろしいことです。

試してみたところ、見た目も動作も同じであるactivate-py35.bat $ファイルとactivate-py35.ps1ファイルを簡単に作成できます（つまり、誰もがactivate-py35を書き込んで、パスを更新するだけです）。 まだ理想的ではありませんが、おそらく悪い状況の中で最高です。

バージョン管理されていないスクリプトにpy.exeを使用すると、実際にどのように機能するかを正確に理解できません。

ポイント（ py.exeにある程度関連しているだけです）は、現在のように特定のハードコードされたPythonインタープリターを呼び出すのではなく、exeラッパーが「何に基づいてインタープリターを動的に選択する必要があるか」ということです。どういうわけかデフォルトです」

「どういうわけか」はpy.exeの出番です-同じルールを使用する必要があります。 ランチャーが自身の名前を確認するように更新された場合、 python.exeを起動する代わりに、代わりに'scripts\\{}{}.{}.exe'.format(argv[0], major_version, minor_version) （ argv[0]などで適切な拡張トリミングを使用）を起動しようとする可能性があります。 次に、インストーラーは、バージョン管理されていないランチャーに、完全にバージョン管理されたランチャーとは異なるファイルを使用する必要があります（これは今日から変更されません）が、そのファイルは、新しい名前の通常のpy.exeになります。 （これは、 pip-script.pyファイルの昔はさらに単純だったかもしれませんが、今ではそれらがなくなっています...）

しかし、あなたが言うように、PATHはまだ問題です。 私には良い解決策はなく、悪い解決策もそれほど多くありません。 環境変数は、実際には、インストーラーではなく、管理者またはユーザーが構成するためのものです。

スクリプトのインストール方法を調整して、ユーザーエクスペリエンスを向上させることができます。 それはすべてバランスが取れており、 .exeと.pyを組み合わせたファイルは、単一の.exeファイルしかないため、ユーザーにとってより良いものになりました。 ただし、 pip install foo && fooで最高のストーリーを取得することは、その特定のものよりも重要だと思います。したがって、 .exeと.pyを再度分離する必要がある場合は、それが良い答えとの良いトレードオフ。

.exe / .pyの分離は、問題の中で最も少ないものです:)

私は実際にactivate-py35のアイデアにウォーミングアップしています（またはしぶしぶ受け入れていますか？）。 私は、PythonをPATHに追加するインストーラーのファンではありませんでした。また、 py -m pipコマンドは実際には勢いを増していません（たとえば、Sphinxでは機能しません）。 activate-pyがどのように機能するかについてのより詳細な説明を書き、それをpython-devに投稿して、それが何らかの牽引力を得るかどうかを確認します。

これらのactivate-whateverファイルは、仮想環境内のファイルと似ていますか？ 仮想環境が$PATHに追加される代わりに、実際のP​​ythonが追加されることを除いて？

うん、ほとんど同じ。 python-devで、 -x.yパラメーターを取り、それをpy.exeに渡し、 sysconfigを使用してパスを取得することを提案しました。

Ok。 私はWindowsユーザーではないので、それがWindowsユーザーにとってどれほど悪いかについては意見がありません。 それは絶対に恐ろしいようには聞こえませんが（多分？）、それは私のWindowsの知識が私を連れて行くことができる限りです。

2015年2月10日午前8時2分、ドナルドスタッフは次のように書いています。

ああ、スクリプトを壊すのはもっと一般的な問題であり、そうではありません
本当に--userに正確に関連しています。 同じ問題がどこにでも存在します
Windows --globalインストールを除く。 その問題の解決策は
この問題とは別に解決する必要がある二次的な懸念/問題。

同意しました。

--globalフラグを使用します。

+1

--userにインストールする場合は、何らかの警告が必要になる可能性があります。
~/.local/binは$PATHにありません。

+1、おそらく警告を抑制するための設定オプションを使用しますか？

基本的には、ある種のdefault-installオプションが必要になります
フォールバック動作を無効にし、 --globalまたは
--user 。

+1

pip 6.0の時点で、マシン固有の構成ファイルが/etc/にあります。
ただし、これらは実行中のPythonのバージョンに固有のものではありません
ピップ。 多少分離しているものの、それは良い機能だと思います（そして
スクリプトの混乱を解決することと密接に関連している可能性があります）。

次のような検索順序をお勧めします。

• pipX.Y.conf
• pipX.conf
• pip.conf

最初に（？）を/ etc / xdg / pipに、次に/ etcにルートします。ここで、XYはもちろん
major.minorバージョン番号。 最初に見つかったものが勝ちます。

私はまだ1つの主要な未解決の質問を見ています：長期的に私たちはいつ何をしたいのか
誰かがsudo pip install fooというか、誰かが
site-packagesディレクトリに書き込みますか？

「site-packages」ディレクトリは1つだけではないことに注意してください。 例えば、
Debian / Ubuntuでは、 sudo pip installを_ever_にインストールしたくありません
/ usr / libですが、/ usr / local / libのみです。 そして忘れないでください、それはここのdist-packagesです
サイトパッケージではありません（$ reasonsのため〜/ .localを除く）。

これは本当に重要なポイントであり、私でも忘れられることがあります。
ドナルドは、サイトローカルディレクトリと
ベンダー-ローカルディレクトリ。 Debianでは、site-localは
/usr/lib/pythonX.Y/dist-packagesであり、pipコマンドがそれに触れることはありません。
一方、vendor-localは/usr/local/lib/pythonX.Y/dist-packagesであり、
一部のシステム管理者がpipインストールするための文書化された一般的なユースケース
そのディレクトリに。

すでに設定ファイルのパスをたどっているので、私が提案するのは
これらを構成可能にします。

• global_install_directory
• global_install_as_sudo（true / false）

1. --globalにインストールします。 これは、最も下位互換性のあるオプションです
   そして、それを入力するときにユーザーが期待することを表している可能性があります。 しかしそれは持っています
   それが（静かに）グローバルなPythonを台無しにするという欠点は、多くの場合
   システムは壊れたシステムを引き起こす可能性があります。

上記の設定可能性により、これはDebianと完全に互換性があります。
Debianスーパーユーザーはsudo pip installが入ることを期待しています
/usr/local/lib/pythonX.Y/dist-packages。 私はそれが「
システム」は、パッケージマネージャーを壊さないため、
システムにインストールされたパッケージ（
/usr/lib/pythonX.Y/dist-packages）、定義され、文書化された方法でこれを行います。

1. --userにインストールすると、壊れたシステムから保護されます（私は思いますか？）
   しかし、rootユーザーが
   /root/.local/インストール。

同意しました、それは予想外です。

1. エラーを出して、ユーザーに--userまたは
   --global手動で。

それで大丈夫ですが、上記の構成スイッチを参照してください。

1. 最初の2つのオプションのいずれかを選択しますが、ディストリビューションができるスイッチを提供します
   3番目のオプションを有効にする/etc/を提出します。

ねえ、なんて素晴らしいオプションでしょう！

4番目のオプションが最適かもしれませんが、私たちは
ある種の解決策にたどり着くことができる場合は、最初に他のオプションの1つを選択してください
これはすべてのプラットフォーム/シナリオで同じように機能し、すべてのプラットフォームで意味があります
可能であれば、プラットフォーム間で一貫した動作をしたいので。

プラットフォームで定義されたさまざまな動作をしても大丈夫です。たとえば、pipには
--dry-runオプションは、少なくともユーザーに何が起こっているのかを正確に伝えます
やることと場所。

「私は書いたので、3番目のオプションはおそらく悪いものだと思います
許可」は、Windows上の誰もが事前に使用しているシナリオになります
Python 3.5、またはCondaを使用する人、またはpyenvを使用する人。 エラーアウト
これらすべての場合に行うのは間違っているように思われ、soemwhatユーザーです
起動するのは不親切です。

デフォルトの構成で--globalinstallが許可されていれば幸いです。
許可があります。 Debianがそれを変えるとは思わない（多分他の人が
別の意見ですが、少なくともそれは私たちに選択肢を与えます）。

だから私は1と2の間でそれは実際に練習がどれほど悪いかということになります
私たちは人々が（概念的に） sudo pip install --global fooをすることだと思います。

Debianでは、/ usr / local / libに移動する限り、これは予想されるユースケースです。
/ usr / libに移動できません。

（これはすべて、外部のvenv-behavior BTWを説明しています。）

• --userが渡されると、常にユーザーサイトパッケージにインストールされます。

+1

• --globalが渡されると、常にグローバルサイトにインストールされます
• パッケージ。

グローバル_ベンダー_パッケージ== + 1、グローバルサイトパッケージ==-1。

• どちらも渡されない場合、フォールバックメソッドを実装します。
  
  
  
  1. 仮想環境にいるかどうかを検出し、仮想環境にある場合はそのように動作します
     
     --globalが渡されました。
  
  

+1、ただし、venv内のこのディレクトリの名前は
/lib/pythonX.Y/site-packages

1. ユーザーサイトパッケージが無効になっているかどうかを検出し、無効になっている場合は無効になっているかのように動作します
   --globalが渡されました。

うーん、これについてはよくわかりません。

1. default-installを見て、それが存在する場合は--userまたは
   それに基づいて-global 。

+1

1. 有効なユーザーがグローバルへの書き込み権限を持っていないかどうかを検出します
   サイトパッケージ、およびそれらが--userが渡されたかのように動作しない場合。

+1

1. 最後に、他のすべての検出方法が失敗した場合は、 --globalのように動作します
   を超えてた。

また、わからない。

これは、非推奨期間がないことを意味し、期待されるのは
--userまたは--globalがない場合は、推測に基づいて最善を尽くします
私たちが実行しているPythonの機能、効果的なユーザー、および
構成されたデフォルトのインストール方法。

合理的な目標のように聞こえます。

明確にするために、私が「グローバルサイトパッケージ」について話すとき、私は主に「distutilsがグローバルに物事をインストールするように私たちに指示するものは何でも」を意味します。 Python自体には「ベンダーローカル」と「サイトローカル」の区別がないため、これは、Pythonにパッチを適用しないダウンストリーム上の同じディレクトリになります。 ただし、Debianでは実際にはdist-packagesディレクトリになり、「グローバル」は実際には「サイトローカル」を意味します。 これは、PythonへのDebuntuのパッチによって処理されるため、pipがサポートするために特別なことをする必要があるものではありません。

言い換えると、Debuntuはdistutilsにパッチを適用してその区別をサポートしているため、pipはすでにDebuntuの/usr/local/../dist-packages/にインストールされています。 ユーザーがなんらかのフラグを渡さずにpipが/usr/../dist-packages/を混乱させるのは、pipがそこからファイルをアンインストールする場合だけです（pipはそのディレクトリを特別なものとは見なさないため、単に物と見なします）。 sys.path ）。 ただし、Debianはpipにパッチを適用して、そこからのアンインストールを防止しています。実際のサポートは、Pythonアップストリームの「ベンダーローカル」サイトパッケージの実際のサポートに依存していると思います。

--userにインストールしていて、〜/ .local / binが$ PATHにない場合は、何らかの警告が必要になる可能性があります。

この警告はどれほど脆弱である可能性がありますか？ 絶対パスに変換されますか？ 大文字と小文字を区別しないファイルシステムでは、大文字と小文字を区別しませんか？ それはWindows上で同等として扱いますか？ シンボリックリンクはどうですか？

スクリプトをインストールしないパッケージをインストールする場合、警告はとにかく関係ありません。

個人的には、警告はおそらく善よりも害を及ぼすと思います。

--userにインストールする場合は、何らかの警告が必要になる可能性があります。
~/.local/binは$PATHにありません。

+1、おそらく警告を抑制するための設定オプションを使用しますか？

Pythonの警告を使用するようにすると、人々は沈黙することができます
組み込みのPython警告を使用します。 私たちがそれを沈黙させる必要を感じたら
すべて。

pip 6.0の時点で、マシン固有の構成ファイルが/etc/にあります。
ただし、これらは実行中のPythonのバージョンに固有のものではありません
ピップ。 多少分離しているものの、それは良い機能だと思います（そして
スクリプトの混乱を解決することと密接に関連している可能性があります）。

次のような検索順序をお勧めします。

• pipX.Y.conf
• pipX.conf
• pip.conf

最初に（？）を/ etc / xdg / pipに、次に/ etcにルートします。ここで、XYはもちろん
major.minorバージョン番号。 最初に見つかったものが勝ちます。

これはこれに正接的にのみ関連していると私は信じているので、これを＃2417に分割します
討論。

私はまだ1つの主要な未解決の質問を見ています：長期的に私たちはいつ何をしたいのか
誰かがsudo pip install fooというか、誰かが
site-packagesディレクトリに書き込みますか？

「site-packages」ディレクトリは1つだけではないことに注意してください。 例えば、
Debian / Ubuntuでは、 sudo pip installを_ever_にインストールしたくありません
/ usr / libですが、/ usr / local / libのみです。 そして忘れないでください、それはここのdist-packagesです
サイトパッケージではありません（$ reasonsのため〜/ .localを除く）。

これは本当に重要なポイントであり、私でも忘れられることがあります。
ドナルドは、サイトローカルディレクトリと
ベンダー-ローカルディレクトリ。 Debianでは、site-localは
/usr/lib/pythonX.Y/dist-packagesであり、pipコマンドがそれに触れることはありません。
一方、vendor-localは/usr/local/lib/pythonX.Y/dist-packagesであり、
一部のシステム管理者がpipインストールするための文書化された一般的なユースケース
そのディレクトリに。

すでに設定ファイルのパスをたどっているので、私が提案するのは
これらを構成可能にします。

• global_install_directory
• global_install_as_sudo（true / false）

pipは実際にはこれらを制御しません（つまり、明らかに高レベルでは制御します
これはファイルを移動するものであるため）、それらはdistutils / sysconfigから取得されます。

pipは、ベンダーローカルディレクトリに触れないようにする必要があると思います。
--vendorのようなある種のフラグが与えられ、ベンダーはこれを使用できるようになります。
ビルドチェーンにピップします。 この概念は、debuntu以外には実際には存在しません
今のところ、彼らのパッチはすでにこれを処理しているので、私はそれが素晴らしいとは思わない
私が言うときに注意することを除いて、この議論に関連しています
「グローバルサイトパッケージ」私はDebubuntuで/usr/local/.../dist-packagesを意味しました
PythonがDebuntuを受け入れる場合、ある時点での「site-local」パッケージ
システムアップストリーム。

1. --globalにインストールします。 これは、最も下位互換性のあるオプションです
   そして、それを入力するときにユーザーが期待することを表している可能性があります。 しかしそれは持っています
   それが（静かに）グローバルなPythonを台無しにするという欠点は、多くの場合
   システムは壊れたシステムを引き起こす可能性があります。

上記の設定可能性により、これはDebianと完全に互換性があります。
Debianスーパーユーザーはsudo pip installが入ることを期待しています
/usr/local/lib/pythonX.Y/dist-packages。 私はそれが「
システム」は、パッケージマネージャーを壊さないため、
システムにインストールされたパッケージ（
/usr/lib/pythonX.Y/dist-packages）、定義され、文書化された方法でこれを行います。

ええ、「システムを台無しにする」は厳しすぎるかもしれません。 主に私はそれを意味します
システムがfooに依存している場合、 sudo pip install fooは問題を解決する可能性があります
互換性のないバージョンのものをインストールします。 ただし、同じケースが当てはまります
基本的に、 `/ usr / local``にインストールするものすべてに当てはまります。

• --globalが渡されると、常にグローバルサイトにインストールされます
• パッケージ。

グローバル_ベンダー_パッケージ== + 1、グローバルサイトパッケージ==-1。

これは逆の意味ですか？

• どちらも渡されない場合、フォールバックメソッドを実装します。
  
  
  
  1. 仮想環境にいるかどうかを検出し、仮想環境にある場合はそのように動作します
     
     --globalが渡されました。
  
  

+1、ただし、venv内のこのディレクトリの名前は
/lib/pythonX.Y/site-packages

ええ、繰り返しますが、Pythonにそのディレクトリがどこにあるかを尋ねるだけで、計算はしません
私たち自身、つまり「そのディレクトリがどこにあるか」はvenv / virtualenvのものです。

1. ユーザーサイトパッケージが無効になっているかどうかを検出し、無効になっている場合は無効になっているかのように動作します
   --globalが渡されました。

うーん、これについてはよくわかりません。

ユーザーサイトのパッケージが無効になっている場合、これを回避する方法はないと思います。
知る方法がないので、そこにインストールする必要があるとは思わないでください
その無効化がユーザーサイトパッケージがないことを意味する場合、またはその理由。 私たちだけができる
何もないと仮定します。

1. 最後に、他のすべての検出方法が失敗した場合は、 --globalのように動作します
   を超えてた。

また、わからない。

これは基本的に次のように要約されます。

理由が見つからない場合は、-userフラグなどの--userを使用するか、
ディレクトリに書き込む権限がない場合は、使用しないでください。 これ
--global sudo pip install fooを維持するものです
働く。 これはまた、これが違反しないための最も重要なルールであることを意味します
sudo pip install fooがこのように動作することを期待する動作するソフトウェア。

--userにインストールしていて、〜/ .local / binが$ PATHにない場合は、何らかの警告が必要になる可能性があります。

この警告はどれほど脆弱である可能性がありますか？ 絶対パスに変換されますか？ 大文字と小文字を区別しないファイルシステムでは、大文字と小文字を区別しませんか？ それはWindows上で同等として扱いますか？ シンボリックリンクはどうですか？

スクリプトをインストールしないパッケージをインストールする場合、警告はとにかく関係ありません。

個人的には、警告はおそらく善よりも害を及ぼすと思います。

さて、私たちはそれを（クロスプラットフォームと同等の）として実装することができます：

def user_bin_on_path():
    paths = os.environ.get("PATH").split(":")
    for path in paths:
        if os.path.realpath(path) == os.path.realpath(USER_BIN_DIR):
            return True
    return False

そのようなものは、シンボリックリンクやパスセパレータなどを処理する必要があると思います。 悪魔は細部に宿り、さまざまなクロスプラットフォームのコーナーケースをカバーするのに十分な精度を得ることができないかもしれません。

スクリプトがインストールされていない場合、警告は無関係であることに同意します。つまり、スクリプトをインストールするときにのみ警告を気にするということです。

基本的な考え方は、-userが暗黙的であるpip install [--user] fooのようなことを誰かに行わせたくないということです。次に、 fooを実行して、ガイダンスなしで「コマンドが見つかりません」を取得します。なぜ見つからないのか。 少なくとも警告は、PATHに何かを追加する必要があることを彼らに伝えます。 また、Windowsのユーザーにユーザーディレクトリを手動でPATHに追加する（またはスクリプトを実行して）ように促すこともできます。これにより、Steveが指摘したactivateスクリプトの必要性が軽減される可能性があります。 それでも、システム値がユーザー値よりも優先されることを意味すると思いますが、PATHとsys.pathの順序が逆になるため、混乱を招く可能性があります。

ドー。 realpathがパスを正規化したことを忘れました。 はい、もちろんそれで十分です。

私を悩ませているのは、テストで誤って問題が検出された場合、ユーザーは、システムを変更してピップ側のミスを回避する以外に、それを回避する方法がなく、迷惑で誤った警告を受け取ることです。 しかし、あなたが提案しているテストはおそらく十分に堅牢であり、スクリプトをインストールしている場合にのみチェックを行うことを考えると、この問題はおそらく無視できるほどまれです。

了解しました。ここでは幅広い合意があると思います。 次のステップはパッチを入手することだと思います。 私は先に進んで、今夜または明日遅くに何かを起こそうとします。

2015年2月10日、午後12時14分、DonaldStufftは次のように書いています。

基本的な考え方は、-userが暗黙的であるpip install [--user] fooのようなことを誰かに行わせたくないということです。次に、 fooと
なぜそれが見つからないのかについてのガイダンスなしで「コマンドが見つかりません」を取得します
見つかった。

Debian、そしておそらく他のLinuxには、実際にはコマンドが見つからないパッケージがあります
これにより、ユーザーが次のコマンドを呼び出すと、パッケージをインストールするように求められます。
インストールされていません。

％inkscape
プログラム「inkscape」は現在インストールされていません。 次のように入力してインストールできます。
sudo apt-get install inkscape

たぶん、プラットフォームをサポートするためにそれにフックすることができます。

2015年2月10日12:06 PMに、DonaldStufftは次のように書いています。

• --globalが渡されると、常にグローバルサイトにインストールされます
• パッケージ。

グローバル_ベンダー_パッケージ== + 1、グローバルサイトパッケージ==-1。

これは逆の意味ですか？

用語を混同する可能性があるので、明示します。

/usr/local/lib/pythonX.Y/dist-packages == +1
/usr/lib/pythonX.Y/dist-packages == -1

しかし、あなたが前に言ったように、これはピップが本当に心配する必要があるものではありません
それはdistutilsから継承されており、Debuntuのdistutilsにパッチが適用されているためです。
正しいことをするために。

1. ユーザーサイトパッケージが無効になっているかどうかを検出し、無効になっている場合は無効になっているかのように動作します
   --globalが渡されました。

うーん、これについてはよくわかりません。

ユーザーサイトのパッケージが無効になっている場合、これを回避する方法はないと思います。
知る方法がないので、そこにインストールする必要があるとは思わないでください
その無効化がユーザーサイトパッケージがないことを意味する場合、またはその理由。 私たちだけができる
何もないと仮定します。

ああ、あなたが今何を意味しているのかわかります。 それは理にかなっていると思います。 私の懸念はそれです
pipが実際に何をするかを予測するのはもっと難しいかもしれませんが、私は
たとえば、ピップが明確に_tell_できるように、-dry-runフラグに満足します。
あなたはそれが何をしようとしているのか。

1. 最後に、他のすべての検出方法が失敗した場合は、 --globalのように動作します
   を超えてた。

また、わからない。

これは基本的に次のように要約されます。

理由が見つからない場合は、-userフラグなどの--userを使用するか、
ディレクトリに書き込む権限がない場合は、使用しないでください。 これ
--global sudo pip install fooを維持するものです
働く。 これはまた、これが違反しないための最も重要なルールであることを意味します
sudo pip install fooがこのように動作することを期待する動作するソフトウェア。

分かりました。 私たちが避けたい主な反ユースケースは次のとおりなので、それは大丈夫だと思います。

normal_user $ pip install foo
ねえ、あなたには許可がありません
normal_user $ sudo pip install foo
HEY YOU JUST BORKED YOUR SYSTEM

「ディレクトリに書き込む権限がないということは、-userを意味します」というルール
その世話をします。

そうそう、コマンドが見つからないことを忘れました。 役に立つかもしれません。 ちなみに、devubtuがデフォルトでパス上にユーザーローカルビンを持っていることを提案する適切な場所を知っていますか？

2015年2月10日午後4時5分、 BarryWarsawnotifications @ github.comは次のように書いています。

2015年2月10日、午後12時14分、DonaldStufftは次のように書いています。

基本的な考え方は、-userが暗黙的であるpip install [--user] fooのようなことを誰かに行わせたくないということです。次に、 fooと
なぜそれが見つからないのかについてのガイダンスなしで「コマンドが見つかりません」を取得します
見つかった。

Debian、そしておそらく他のLinuxには、実際にはコマンドが見つからないパッケージがあります
これにより、ユーザーが次のコマンドを呼び出すと、パッケージをインストールするように求められます。
インストールされていません。

％inkscape
プログラム「inkscape」は現在インストールされていません。 次のように入力してインストールできます。
sudo apt-get install inkscape

たぶん、プラットフォームをサポートするためにそれにフックすることができます。

—
このメールに直接返信するか、GitHubで表示してください。

2015年2月10日午後1時17分、ドナルドスタッフは次のように書いています。

そうそう、コマンドが見つからないことを忘れました。 役に立つかもしれません。 ちなみにあなたは
devubtuにユーザーローカルビンがあることを提案する適切な場所を知っている
デフォルトのパス？

明確ではありませんが、おそらくadduserまたはpasswdパッケージですか？ 前者は所有しています
/ usr / sbin / adduserおよび後者は/ usr / bin / useraddを所有します。

最初のパス： https ：//github.com/pypa/pip/pull/2418

これが役立つかどうかはわかりませんが…

• 〜/ .local / binは多くの人の$ PATHにありませんが、これについて何かできることはありますか？

他のいくつかのプロジェクトでは、$ PATHにディレクトリを追加するために/etc/profiled.d/を使用しています。 少なくともAntergosでは、次のように表示されます（これらが何をするのか誤解しない限り）jre.csh、jre.sh、perlbin.csh、perlbin.sh。

# Do not change this unless you want to completely by-pass Arch Linux' way
# of handling Java versions and vendors. Instead, please use script `archlinux-java`
setenv PATH "${PATH}:/usr/lib/jvm/default/bin"

# Do not change this unless you want to completely by-pass Arch Linux' way
# of handling Java versions and vendors. Instead, please use script `archlinux-java`
export PATH=${PATH}:/usr/lib/jvm/default/bin

# Set path to perl scriptdirs if they exist
# https://wiki.archlinux.org/index.php/Perl_Policy#Binaries_and_Scripts
# Added /usr/bin/*_perl dirs for scripts
# Remove /usr/lib/perl5/*_perl/bin in next release

[ -d /usr/bin/site_perl ] && setenv PATH ${PATH}:/usr/bin/site_perl
[ -d /usr/lib/perl5/site_perl/bin ] && setenv PATH ${PATH}:/usr/lib/perl5/site_perl/bin

[ -d /usr/bin/vendor_perl ] && setenv PATH ${PATH}:/usr/bin/vendor_perl
[ -d /usr/lib/perl5/vendor_perl/bin ] && setenv PATH ${PATH}:/usr/lib/perl5/vendor_perl/bin

[ -d /usr/bin/core_perl ] && setenv PATH ${PATH}:/usr/bin/core_perl

# If you have modules in non-standard directories you can add them here.
#export PERLLIB=dir1:dir2

# Set path to perl scriptdirs if they exist
# https://wiki.archlinux.org/index.php/Perl_Policy#Binaries_and_Scripts
# Added /usr/bin/*_perl dirs for scripts
# Remove /usr/lib/perl5/*_perl/bin in next release

[ -d /usr/bin/site_perl ] && PATH=$PATH:/usr/bin/site_perl
[ -d /usr/lib/perl5/site_perl/bin ] && PATH=$PATH:/usr/lib/perl5/site_perl/bin

[ -d /usr/bin/vendor_perl ] && PATH=$PATH:/usr/bin/vendor_perl
[ -d /usr/lib/perl5/vendor_perl/bin ] && PATH=$PATH:/usr/lib/perl5/vendor_perl/bin

[ -d /usr/bin/core_perl ] && PATH=$PATH:/usr/bin/core_perl

export PATH

# If you have modules in non-standard directories you can add them here.
#export PERLLIB=dir1:dir2

ランダムなpipユーザーとして、このようなユーザーエクスペリエンスの問題に取り組み、ユーザーエクスペリエンスの向上マイルストーンでキャプチャされた他の問題と同様に_ありがとう_と言いたいだけです。 この取り組みに経済的に貢献できる場所はありますか？

余談ですが、私はHomebrewを使用しており、 brew install somethingで十分であり、許可に煩わされることなく機能するという事実を常に高く評価しています。

Homebrewでインストールするのにsudoが必要ない理由を理解したら、 pip install --user somethingを実行する習慣を身につけようとしましたが、皮肉なことに、distutilsのバグが報告されているため、 Homebrewはこれを無効にします。

OS XでのHomebrewの人気を考えると、おそらく、Homebrewとpip install --userのこの非互換性を調べたいと思うでしょう。

とにかく、 --userをデフォルトにすることで私から+1します。

簡単なフォローアップ。 Didierは、-userをデフォルトとして設定する変更をUbuntuのpipに鮮やかにアップロードしました。 私もほとんど許可しましたが、今は間違いだったと思います。それを元に戻すつもりです（ただし、鮮やかな変更をSRUすることはおそらくないでしょう）。 詳細と理論的根拠については、 https：//bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1460203を参照してください。

ユーザーとシステムの区別は、プラットフォームの違いが関係することなくすでに十分に混乱しているため、アップストリームにこの変更のタイミングを駆動させるための+1。

とは言うものの、Linuxディストリビューションは、ユーザーごとまたはvenvごとのインストールは、予測できない副作用を伴う可能性のある悪いアイデアとして確立されています。

私は@warsawに個人的に話しましたが、ここでも言います：

この変更は重要だと思います。プルリクエストに戻って終了する予定です。 ただし、私は1人で複数のプロジェクトにまたがっています。現在、この変更よりもWarehouseの方が重要です。これは、PyPIのレガシーの運用がますます負担になり、できるだけ早く交換する必要があると感じているためです。 したがって、pipでの私の時間は、自分で多くの変更を加えることに焦点を当てているのではなく、他の寄稿者が行った変更やリリースプロセスのものをガイドすることに焦点を当てています。

そうは言っても、誰かがこの機能を後でではなく早く着陸させることを本当に気にかけているなら、彼らは私の仕事を手に取ってそれを終えることができます。 それをやりたいと思っている人と話し合い、変更についてのガイダンスを提供できることをうれしく思います。 それ以外の場合は、私がより私に迫っているアイテムを完成させるまで待つことになります。

おそらく、この時点で繰り返す価値があります。

'default to --user'に反対することになった場合は、混乱の少ない代替案を検討する必要があります。

1. --userへのフォールバック（perimissionsエラーが原因でインストールが失敗した場合）
2. （ペリミッションエラーが原因でインストールが失敗した場合）、ユーザーに（大きな親しみやすい文字で）-userを試すように促します

FWIW、Python 3.5のWindowsインストーラーがユーザーごとのインストールを強く推奨しているので、pipで発生するこの変更についてはそれほど心配していません。 新しいデフォルトやフォールバックよりも、（ --globalオーバーライドを使用した）ディストリビューションの構成オプションの方が優れている可能性があります。

この問題を+1するために立ち寄って、これに取り組んでくれてありがとうと言いたかっただけです！ 私たちは現在、科学的なPythonサマースクールを運営しており、許可の問題に遭遇したときに多くの人々 sudo pip installがありました。

FWIWデフォルトで--userにするか、権限エラーのためにインストールが失敗した場合--userにフォールバックすることに賛成です。 この場合、失敗して再試行する方法を教えるのではなく、彼らが行ったことを元に戻すように指示することをお勧めします（たとえば、 We installed to your user directory. If you don't want this, then 'pip uninstall my_package' ）。

--userによるモックのバグレポートがたくさんあります-少なくともUbuntuでは、パス上の--userの場所はdist-packagesの後にあるため、インストールされているpipは、一般的な依存関係（ 6）それはdist-packagesにあります。

彼らはそれを_after _ dist-packages ？ それは壊れたインストールIMOです。

そうです、ユーザーのインストールはsite（/ dist）-packagesの前に行う必要があり、システムスクリプトとユーティリティは-I（またはPython 2では-Es）で実行する必要があります。

はい私は同意する ：）。 鮮やかに修正されるかもしれませんが、物事が完全に間違った場所から来ているという報告は間違いなくあるようです。

システムピップを使用して、鮮やかなマシンにsetuptoolsをインストールし、実験しました。

>>> import setuptools
>>> setuptools.__path__
['/home/robertc/.local/lib/python2.7/site-packages/setuptools']
>>> import sys
>>> sys.path
['', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/home/robertc/.local/lib/python2.7/site-packages', '/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages/PILcompat', '/usr/lib/python2.7/dist-packages/gtk-2.0', '/usr/lib/pymodules/python2.7', '/home/robertc/work/mock']

だからこれは正気です。 しかし、紛らわしいことに、これは鮮やかに導入されました-つまりIDK。 ある時点でリプロデューサーを掘り起こすことができるかどうかを確認します（Ubuntu BTSにファイルするため）

ページング@warsaw

ユーザーのサイトパッケージは、setuptoolsの邪悪な.pthファイルによってグローバルサイトパッケージの後に再配置される可能性があります。 setup.pyを直接使用しないことを学ぶまで、これらは私にとって繰り返し発生する問題でした。何かをインストールすると、突然、他のあらゆる種類のものの古いバージョンを使用していました。 数回後、私は自分のシステムを解き放つための攻撃的なツールを書きました。

少なくとも当面の間、pipは、コマンドが失敗した場合にユーザーに--userを実行するように求めるわかりやすいメッセージを出力する必要があると思います。 デフォルトに切り替えることには利点がありますが、より良いメッセージを印刷するのはそれほど難しいことではありません。

これは、実際にデフォルトの--userに移行するまでは、問題の「迅速な修正」になります。

/etc/pip.confでユーザーモードが設定されている場合は、-global、-system、または--no-userも必要です。 私の知る限り、ユーザーがこれをオーバーライドする簡単な方法はありません。

それは問題の素晴らしい「クイックフィックス」です

後期更新：＃4233がこれを行いました。

Windowsを使用していない人（特に初心者）は、良い体験をしたい場合は、実際にはhttps://github.com/pyenv/pyenvにアクセスする必要があります。 特に~/.localはXDG_DATA_HOMEであるため、PEP370は今日私にはあまり意味がありません。

この行動が発生した場合にオプトアウトするのは私だけではないと思います。 移行がスムーズになり、システムの動作を変更したり、追加のCLIフラグを渡したりする必要がないことを願っています。これは、pyenvに非常に満足しているためです。 もちろん、pyenvがWindowsでどれだけうまく機能するかはわかりませんが、bashサブシステムが役立つ可能性があります...

@jcrben pyenvは、人々がPythonをどのように使用しているか（特にPythonバイナリをどのように取得しているか）についてかなりの数の仮定を立てています。つまり、これらの仮定が有効な人々にとっては非常にうまく機能しますが、デフォルトの推奨事項になるほど普遍的ではありません（その点ではcondaに似ています）。

pipレベルのデフォルトの--userは、適切に構成されたPython仮想環境内では効果がないため、この変更がcondaやpyenvなどのサードパーティ環境マネージャーに与える影響pipや他のツールが検出する方法で（つまり、 virtualenvが報告する方法で、環境ステータスを正しく通知していることを確認する必要があります。または、標準ライブラリのvenvと同じように）。

関連する提案： https ：//github.com/pypa/pip/issues/1056#issuecomment-218130183。

〜 ~/.localに直接インストールしないように、ユーザーがディレクトリを（おそらくenv変数を介して）カスタマイズできるようにすることは検討されていますか？ 私はおそらくそれらを~/.local/pipか何かにネストしたいと思います-私に関する限り、Pythonにはその共有スペースのトップレベルに対する特別な権利はありません。 〜9.0.1では、 ~/.local/lib/python<version>の下にあるものをネストし、さらに~/.local/binに実行可能ファイルを追加するようです。これは問題ないと思います...

@jcrbenはい、ターゲットの場所は実際にはPythonのユーザーサイトディレクトリです。これは、システムのsite-packagesディレクトリの命名スキームを反映しています： https ：//docs.python.org/3/library/site.html#site.USER_SITE

これは、 PYTHONUSERBASE環境変数を使用して、インタープリターレベルで既に構成可能です： https ：//docs.python.org/3/using/cmdline.html#envvar -PYTHONUSERBASE

興味のある方のために、 https：//github.com/ofek/hatchをリリースしました。これには、デフォルトでこの動作が行われるパッケージコマンドinstall 、 uninstall 、およびupdateが含まれています。 システムを変更する場合、ユーザーはhttps://github.com/npm/npmと同様の-g/--globalオプションを使用できます。

PyPI上のマルウェアに感染したパッケージに関する最近の問題を考えると、特にセットアップスクリプトがインストール時に任意のコードを実行する可能性があることを考慮すると、 sudo pip install ...の使用を阻止するためにできることを行うことがpipの最大の利益になると思います。 感染したパッケージをユーザーとしてインストールすることは十分に悪いことですが、rootとしてインストールする場合はさらに悪いことになります。

ユーザーインストールをデフォルトに設定すると、pipコマンドの前にsudoを追加する人が少なくなります。つまり、誤ってインストールされたマルウェアの処理が少なくなる可能性があります。

具体的な次のステップとして、 --globalフラグを追加するための別の問題を発生させました： https ：//github.com/pypa/pip/issues/4865

これは、virtualenvまたはconda環境ではほぼ間違いなく悪い考えです。 ある環境がアクティブなときに.localにインストールされたものはすべて、別の環境を簡単に破壊する可能性があります。 では、そのような場合の考え方は何でしょうか。

cc @msarahan @kalefranz

この問題は、アクティブな仮想環境内では適用されません。アクティブな環境が検出されず、ターゲット定義オプション（ --prefix 、 --rootなど）が指定されていない場合にのみ適用されます。コマンドラインで。

これはどのように決定されますか？

@jakirkham https://github.com/ofek/hatch/blob/df2c9d46ee7713a1bc156c361cfd0f78e5935297/hatch/utils.py#L19 -L25

conda環境内のPythonのsys.pathでデフォルトで~/.localを無効にすることを検討してきました。これは、定義上、condaによってインストールされたPythonです。 ただし、注意が必要です。 いずれにせよ、ユーザーのグループの期待に違反してしまう可能性があります。 https://github.com/conda/conda/issues/7173でのディスカッション

PIP_で始まる環境変数からpipが引数をロードできませんでしたか？ これは--userで機能しますか？ 完全な変数名は何でしょうか？

それはPIP_USERになります。

ドキュメント： https ：//pip.pypa.io/en/stable/user_guide/#environment -variables

PIP_USER=yes正確には、ありがとう！ 環境変数の使用は、CIの使用がはるかに簡単です。これは、環境変数を1回定義するだけで、コマンドが呼び出されるたびに使用されるためです。

どうやらいくつかのステージがvirtualemvなしで通常のユーザーとして実行され、いくつかはvirtualenv内で実行される、travisに対していくつかの本当に醜いロジックを実行する必要がありましたが、どちらになるかわかりません。

virtualenvの内部では、サイトパッケージを使用しなかった場合にユーザーが失敗する可能性があります（これにより他の問題が発生します）。

bashでvirtualenvを検出し、—userを追加しないようにする必要があったこのメントは、失敗します。

これは醜く、デバッグに多くの時間を浪費する原因になりました。他の人も同じように直面すると確信しています。

インストールに関するフォールバックをアクティブにするオプションが必要だと思います。可能であればユーザーにインストールして、システムにフォールバックするなどです。

パッケージをインストールする場所が見つからない場合にのみ、pipは失敗します。

これに関する動きはありますか？

私はそれが言及されているのを見ませんでしたが、sudoの下で実行されたときに--userが渡された場合、おそらくpipは文句を言うはずです。

これらの未解決の問題により、プログラマーはpipやpythonから離れ、他のパッケージやjavascriptやnpmなどの他のプログラミング言語を使用するようになり、このような問題は少なくなります。 Pythonを使用したい新しい初心者にとって、これらの余分な必要なオプションはイライラします。

--userがデフォルトになるのはなぜですか？ 明示的に指定することはできませんか？ ユーザーと組み合わせて使用​​できないと文句を言うため、pip--targetを実行できません。 それを回避する方法はありますか？

@dmikov ：これはデフォルトではありません。 Debian / Ubuntuの壊れたバージョンを使用している場合を除き、その場合は、 PIP_USER=0 pip install -t ...を使用して自動的に設定される--userを回避できます。 または、公式バージョンをインストールして使用することをお勧めします。

私は夜に--userオプションがデフォルトになることを夢見ていました（冗談ではありません）、私の夢がすぐに実現する可能性はありますか？

pygameをインストールするのに助けが必要ですそれは無効な構文を言い続けます

使用しました
python3 -m pip install -U pygame --user
これは間違っていますか？

@ flamedro56 ：ランダムな問題についてコメントする代わりに、新しい問題を開いて、詳細情報を提供してください：Pythonバージョン、pipバージョン、オペレーティングシステム、コマンド出力...

インストーラーreCAPTCHA

新しい構成オプションdefault = system、userを使用するのはどうですか？ 「virtualenvでも常にユーザー」という意味だと誰も思わないほど明確になります。 それは優雅な移行パスを可能にするでしょう。

＃4575を参照してください。

Manjaroが--userをデフォルトとして設定しようとしているようです。

この問題について上流から何か新しいことはありますか？

@Tids ： "filesystem-2018.9-3はデフォルトで$ HOME / .local / binを$ PATHに追加します。" Manjaroが正しく行っている重要な追加の部分です。

Debianは、Pythonレベルの「defaultto --user」と、ユーザーアカウントレベルの「$ HOME / .local / binはデフォルトでは$ PATHにありません」を組み合わせており、これが問題を解決する組み合わせです。

＃7002では、グローバルsite-packages dirが書き込み可能でなく、ユーザーsite-packagesが有効になっている場合に、デフォルトでpipにユーザーインストールを実行させようとしました。 これにより、envを変更する権限がある限り、envにインストールする場合にユーザーインストールを実行することを大幅に回避できます。

私は最初にアイデアの議論を探しています-それを行うことがまったく意味があるかどうかを考える前に、実装のレビューに行き詰まらないようにしましょう。

（pip自体の）ユーザーインストールと非ユーザーインストールの混合には問題があります。最近の一例として＃7209を参照してください。

この問題に直接関係するわけではありませんが（実際、デフォルトでユーザーに設定すると、状況が多少緩和される可能性があります）、デフォルトとして--userへの移行をどのように処理するかを慎重に検討する必要があります。

（私は主にこのコメントをここに追加しているので、どこかに記録されています-これはほとんどpipの問題ではなく、PythonのUSER_SITEディレクトリが一般的にどのように機能するかという複雑さであり、 --userでインストールするユーザーには十分に理解されていません

PATH （コマンドの検索用）とsys.path （Pythonインポートの検索用）の優先順位が逆であるため、あるインストールのランチャースクリプトがパッケージを他の。 おそらくpipに固有のものではなく、スクリプトをインストールするパッケージに影響を与える可能性があります。

それについて何ができるかはわかりませんが、考える価値があると思います。

そうです、それが私が念頭に置いていた主な「USER_SITEの複雑さ」です。 IMO、ラッパースクリプトを非推奨にし、 python -m pipのみをサポートすることが最も効果的なソリューションです。 （私はラッパー自体に反対していませんが、ラッパーで見られる問題は通常、誤って間違ったラッパーを実行している人です。したがって、ラッパースクリプトの問題を修正することは、通常、それ自体がpipの問題ではなく、「ユーザー環境の設定ミスの診断と修正」です。 " 問題）

pipラッパースクリプトを非推奨にすることを意味しますか、それともpipがインストールできるものとしてラッパースクリプトを非推奨にすることを意味しますか？

後者については確かに-1です。問題が発生した場合でも、コマンドをインストールする機能は非常に便利です。

python -m pip pipを廃止する方が、より合理的かもしれません。 pipは実行中のPython環境にインストールされるため、どちらが実行されているかを明確にすることは理にかなっています。 しかし、それでも利便性が失われ、人々が慣れているものに大きな打撃を与えるでしょう。

具体的には、pip自体のラッパースクリプトを意味しました。 利便性が失われることに同意しました。何らかの形でそれらを保持することに反対するつもりはありませんが（＃3164は、ラッパーを提供するだけの新しいpip-cliプロジェクトがあることを示唆しています）、重要なポイントはpython -m pipです。 サポートされている手段です。

現在のpython （PATH内またはpython -m pip $で使用されるもの）が$＃で使用されるpip pythonでない場合、pipラッパースクリプトを呼び出すことができませんでした。 pip ？ このように呼び出された場合、おそらくpython -m pipに委任することさえできますか？

同様に、pipenvは、ユーザーがすでにvirtualenvにいる場合は警告を発し、その場合は、警告を発した後、それ自体を管理する代わりにそのvirtualenvを使用します。

さて、ここで＃7002がこの時点で6人のピップメンテナのうち3人によって承認されていることに注意してください。

デフォルトでは、pipが非ユーザーインストールからユーザーインストールに切り替わります。ほとんどの場合、実際にユーザーインストールを実行する必要があります。 この変更を行うことに関して、私は2つのより広い懸念を持っています。それは、その拡張を行うリリースを作成する前に理解する必要があるということです。

• デフォルトで切り替えた後、ユーザーインストールを明示的にオプトアウトするメカニズムが必要ですか？ もしそうなら、それは--no-userとどう違うのでしょうか？ （明示的なオプトアウトとして--no-userの名前を--globalに変更するために参加しています）。
• 私たちの「移行」戦略とは何ですか？
  
  
  
  • この変化をどのように伝えたいですか？
  
  
  • このアップグレードを行うときは注意するようにユーザーに伝えますか？
  
  
  • この変更が実装されてリリースされた場合、ユーザーはどのような問題を提起すると予想されますか？
  
  

環境内にいる場合、 --globalの名前は間違っていると思います。 flit installの場合、 --userの反対は--envであり、これは大まかに「システムPython環境」を含めることを意味しますが、それも完全に明確ではないと思います。 たぶん--no-userはまだ最良の選択です-それは明らかに--userの反対です。

現在のデフォルトは事実上user = Falseであるため、 --no-user （または同等の環境変数または構成エントリ）で既存の動作を取り戻す必要があると思います。

変更が混乱する可能性があると私が思いついた唯一のシナリオは、実際にはインストールしない環境（ユーザーサイトが有効になっている、たとえばconda）にインストールする権限があると思う場合です。失敗は実行するよりも明確です。ログメッセージがある場合でも、ユーザーがインストールします。 私はそれを改善するための良い方法を考えていません。

書き込み可能性の検出が失敗する可能性もあります。 誤検知は、既存の動作を提供するだけです（通常のインストールを試して失敗します）。 フォールスネガティブは、通常のインストールを実行できたときにユーザーインストールを実行します。

デフォルトでは、pipが非ユーザーインストールからユーザーインストールに切り替わります。

（たとえば）Windowsではありません。（デフォルトで）Pythonのインストールはユーザーごとのインストールであり、サイトパッケージはデフォルトで書き込み可能です。 この号（＃1668）が開かれて以来の私の経験では、pipのようなパッケージが両方のサイトパッケージにインストールされている「混合」環境では簡単に混乱する可能性があるため、これは私が一般的に＃7002について好むものです。およびユーザーサイト。 そのため、可能な限りシステムのインストールを実行し、サイトパッケージを書き込めないLinuxシステム管理のPythonのような場合にのみユーザーのインストールを実行することに賛成です。

そうは言っても：

1. ＃7002は、システムのインストールが失敗した場合にのみユーザーインストールを取得することを意味するため、 --no-userオプションには意味がないようです。
2. 移行に関して私たちが伝える必要があると思う最大のことは、人々は複数のインストールに非常に注意する必要があるということです。これは、pipの回避策ではなく、ユーザーの理解と教育によってのみ対処できます。 これは基本的にPythonのコアの問題です。 pip checkを拡張して、サイトとパッケージのユーザーインストールがあり、ユーザーがサイト1をシャドウイングしている場合にレポートすることができます...

--no-userオプションには意味がないようです

明確にするために、これはすでに存在しますが、おそらくあまり役​​に立たないでしょう。 構成ファイルにuser=trueがある場合、 --no-userはそれをオーバーライドする必要があります。

明確にするために、これはすでに存在します

申し訳ありませんが、私はもっと明確にすべきでした。 少なくとも@pradyunsgが意味していると仮定するという意味では、「デフォルトでユーザーのインストールを明示的にオプトアウトするメカニズム」があることに意味はありません。これは、＃7002の動作をオプトアウトすることを意味します。私が言ったように、「デフォルトでユーザーインストールに切り替える」と同じではありません。

実際、それがより明確かどうかはわかりません;-)たぶん私が言いたいのは「現在持っているものよりも多くのオプションは必要ない」ということだけです...

うーん... @ pfmoore ＃7002の後、この問題を解決したと呼ぶには何が必要ですか？

PS：私は急いでその以前のコメントを書きました、そしてそれは誤って投稿されました。 弾丸はOKです。 それが投稿されたとき、私はまだその前の段落を起草していました。 混乱を引き起こした可能性があります。

@pradyunsg絶対に必要でない限り、デフォルトとして--userを使用するのは良い考えだと思う傾向がはるかに少なくなっていることを考えると（ケース＃7002アドレス）、この問題を次のように放棄できると言いたいです。 ＃7002が完了したので、もはや良い考えではありません。

＃7002を完全なものとして数える必要があるかもしれないものとして、あなたの2つの箇条書きを取り上げて、上記の私のコメントはそれをカバーしています。

ここでリリースノートに従いました。
https://pip.pypa.io/en/stable/news/#id3
「メインのsite-packagesディレクトリが書き込み可能でなく、ユーザーのsite-packagesが有効になっている場合、デフォルトで（--userが渡されたかのように）ユーザーインストールを実行します。（＃1668）」

私のビルドは今失敗しています

ERROR: Can not perform a '--user' install. User site-packages are not visible in this virtualenv.

これは、pipコマンドから--userを削除することで修正されたようです。

これは予想される動作でしたか？ リリースノートはこれを反映していないようです。

pip 20.0.1で失敗するスクリプトへのリンク（--userを削除するとハード失敗が修正されます）
https://github.com/lfit/releng-global-jjb/blob/master/shell/python-tools-install.sh

ユーザーサイトパッケージがその環境からインポートできないことが正しい場合、それは予想される動作ですが、このPRと直交しています。 そのチェックは数年前に導入されましたが（＃567）、最近までvenvで壊れていたようです（＃7155）。 そのためのリリースノートがあります：

venv（PEP 405）で作成された仮想環境で、システムサイトパッケージを正しく処理します。

はい、コメントありがとうございます。 私はこれを理解しました...
私のスクリプトは.local / bin /にデータを入力していました
私が走ったとき

python3 -m venv ~/.local

次に、ubuntuログインシェル（＃！/ bin / bash -l）で.local / binがパスに追加されます（したがって、python3を呼び出すと.local / bin / python3実行可能ファイルが呼び出されます）。
python3 -m venv〜 / .localを実行する必要はありませんでした
または、ログインシェルからスクリプトを呼び出し、これらの問題の両方またはいずれかを削除すると修正されます。

#fresh ubuntu docker
root<strong i="13">@7d8107816f64</strong>:/# python3 -m pip install  --user --upgrade pip
Successfully installed pip-20.0.1
root<strong i="14">@7d8107816f64</strong>:/# python3 -m pip --version
pip 20.0.1 from /root/.local/lib/python3.6/site-packages/pip (python 3.6)
root<strong i="15">@7d8107816f64</strong>:/# ls root/.local/bin/pip
pip     pip3    pip3.6
#Now we populate ~/.local/bin/
root<strong i="16">@7d8107816f64</strong>:/# python3 -m venv ~/.local
root<strong i="17">@7d8107816f64</strong>:/# ls root/.local/bin/
activate          activate.fish     easy_install-3.6  pip3              python
activate.csh      easy_install      pip               pip3.6            python3
root<strong i="18">@7d8107816f64</strong>:/# ./root/.local/bin/python --version
Python 3.6.9
root<strong i="19">@7d8107816f64</strong>:/# ./root/.local/bin/python -m pip install  --user --upgrade pip
ERROR: Can not perform a '--user' install. User site-packages are not visible in this virtualenv.

したがって、実行可能ファイル.local / bin / pythonを実行した場合、-userを使用してpipinstallを実行することはできません。

ああ、あなたがpython3 -m venv ~/.localをやっていたのを見逃しました。 ~/.localは--userインストールのプレフィックスであるため（Linuxの場合）、pipなどのツールを混乱させる可能性があります。 venvsと--userは、システム全体に変更を加えずにパッケージをインストールできる2つの_異なる_方法です。どちらか一方を使用する必要があります。 ~/.localでvenvを作成すると、2つの奇妙なハイブリッドが作成されます。

新しい動作はおそらく多くの人にとって便利ですが、「ユーザー」のインストールにより、Web開発者としての不満が生じました。本番マシンにデプロイされるvirtualenvを準備する必要があります。また、ユーザーライブラリにパッケージがインストールされている場合は、その後、デフォルトでpipは、準備中のvirtualenvへのインストールを拒否し、それでも成功して終了します。 パッケージをインストールしないことを決定したという通知は、virtualenvの準備に使用するスクリプトからの30ページまたは40ページの出力に埋め込まれています。 最終的な効果は、virtualenvがデプロイされると、ホームディレクトリからのパッケージが利用できなくなるため、一部のランダムなパッケージが本番Webアプリから欠落し、完全に機能しなくなることです。

私のユースケースは典型的なものではないことを認めたいので、一般的なユーザビリティの観点からは、これはまだ良い考えだったのかもしれません。

同様の問題を抱えている他の人にとって、それを回避するいくつかの方法があります：

• スクリプトなどのすべてのpip installコマンドラインに--force-reinstallを追加します
• ~/.local/lib/python*を編集して、 globalセクションにuser = no ~/.pip/pip.confを追加します。

[global]
user = no

• ~/.local/libをディレクトリではなくファイルに変更するなど、もっと抜本的なことをしてください：smirk：

いつものように、親愛なるパッケージのメンテナ、あなたがするすべてに感謝します-誰かのものを壊さずに何かを変えることは事実上不可能であると私は確信しています、そしてあなたがとにかく偽造するという事実は私たちが進歩することを可能にするので実際に素晴らしいです。

ああ、ユーザーのインストールは、多くの異なるものが同じユーザーアカウントとして実行される継続的インテグレーション環境でも大きな問題を引き起こす可能性がありますが、それでも人々はビルドが互いに分離されることを期待しています。 ~/.localを読み取り専用にすることでこれを解決しましたが、上記の解決策もおそらく機能します。

デフォルトのオプションを使用してvirtualenvを作成すると、それは分離されます。ユーザーまたはシステムのサイトパッケージを表示できないため、pipはenvにインストールされたパッケージでのみ機能するはずです。 あなたが説明する問題の種類が正確であるため、これは何年も前にデフォルトになりました。

--system-site-packagesオプションを使用してvirtualenvsを作成する場合（または、それがデフォルトであった非常に古いバージョンのvirtualenv）、システム全体とホームの両方でインストールしたパッケージのオーバーレイとして機能します。ディレクトリ。 システムパッケージを表示したいがユーザーパッケージは表示したくない場合は、 -sオプションまたはPYTHONNOUSERSITE環境変数を使用してPythonを実行できます。

おー！ ごめんなさい、あなたは完全に正しいです。 私の組織の奇妙なsystem-site-packagesポリシーが再び適用されます。 いくつかの解決策を指摘していただきありがとうございます。

問題ない。 システムサイトパッケージは、数年前、numpyなどのシステムパッケージマネージャーに依存することが多かったため、より一般的でした。そのため、そのポリシーを再検討する価値があるかもしれません。 しかし、今日でもそれを使用する賢明な理由があるかもしれません。

https://github.com/pypa/pip/issues/1668#issuecomment-544569965に沿って締めくくります。

@takluyverに感謝します！ ^> ^

@takluyver長い間悩んでいた問題を解決していただきありがとうございます
しかし、非特権ユーザーでパッケージをインストールする場合、Windows 10 python 3.8.2とpip20.0.2は依然としてハードフェイルであることに気付きました。

ERROR: Exception:
Traceback (most recent call last):
  File "c:\program files (x86)\python38-32\lib\site-packages\pip\_internal\cli\base_command.py", line 186, in _main
    status = self.run(options, args)
  File "c:\program files (x86)\python38-32\lib\site-packages\pip\_internal\commands\install.py", line 253, in run
    options.use_user_site = decide_user_install(
  File "c:\program files (x86)\python38-32\lib\site-packages\pip\_internal\commands\install.py", line 604, in decide_user_install
    if site_packages_writable(root=root_path, isolated=isolated_mode):
  File "c:\program files (x86)\python38-32\lib\site-packages\pip\_internal\commands\install.py", line 548, in site_packages_writable
    return all(
  File "c:\program files (x86)\python38-32\lib\site-packages\pip\_internal\commands\install.py", line 549, in <genexpr>
    test_writable_dir(d) for d in set(get_lib_location_guesses(**kwargs))
  File "c:\program files (x86)\python38-32\lib\site-packages\pip\_internal\utils\filesystem.py", line 140, in test_writable_dir
    return _test_writable_dir_win(path)
  File "c:\program files (x86)\python38-32\lib\site-packages\pip\_internal\utils\filesystem.py", line 153, in _test_writable_dir_win
    fd = os.open(file, os.O_RDWR | os.O_CREAT | os.O_EXCL)
PermissionError: [Errno 13] Permission denied: 'c:\\program files (x86)\\python38-32\\Lib\\site-packages\\accesstest_deleteme_fishfingers_custard_m59lch'

これは、 OSErrorのerrnoがerrno.EACCESあるが、 errno.EPERMであることが原因であると考えました。

@catPill正しく追跡できるように、新しい問題を開いてください。 私がWindowsで何かを逃したことは完全にもっともらしいです。