<p>ディレクトリのpipインストールは非常に遅い</p>

.gitを含むディレクトリ全体のコピーを作成しています。 おそらくそうすべきではありません。

$ du -sh pip
263M    pip

$ du -sk * .cache .git .tox .travis | sort -nr | head -n 5
181860  .tox
34836   tests
31700   .git
9212    pip
2852    build

3つの-v （ time pip install -vvv --no-install ~/dev/git-repos/pip ）を渡してみましたが、それ以上の情報は得られませんでした。

pdbを使用してステップスルーすると、次のようになると処理が遅くなります。

> /Users/marca/dev/git-repos/pip/pip/req/req_set.py(365)prepare_files()
-> unpack_url(

そして、うん、

> /Users/marca/dev/git-repos/pip/pip/download.py(635)unpack_file_url()
-> shutil.copytree(link_path, location, symlinks=True)

$ time pip install --no-install ~/dev/git-repos/pip
DEPRECATION: --no-install and --no-download are deprecated. See https://github.com/pypa/pip/issues/906.
Processing /Users/marca/dev/git-repos/pip
  2014-12-15 15:23:34.630794: Copying tree; link_path = '/Users/marca/dev/git-repos/pip'; location = '/var/folders/gw/w0clrs515zx9x_55zgtpv4mm0000gp/T/pip-D6etc4-build'
  2014-12-15 15:23:57.418679: DONE copying tree; link_path = '/Users/marca/dev/git-repos/pip'; location = '/var/folders/gw/w0clrs515zx9x_55zgtpv4mm0000gp/T/pip-D6etc4-build'
  Requirement already satisfied (use --upgrade to upgrade): pip==6.0.dev1 from file:///Users/marca/dev/git-repos/pip in /Users/marca/dev/git-repos/pip
pip install --no-install ~/dev/git-repos/pip  2.75s user 5.03s system 32% cpu 24.168 total
>>> elapsed time 24s

https://github.com/pypa/pip/issues/2196でのいくつかの議論

https://github.com/pypa/pip/pull/2196がマージされたため、はるかに高速になりました。

＃2196が元に戻されたため、これを再度開く必要があります。 ヒューリスティックを使用して何をコピーするかを判断する代わりに、sdistを構築する代替PRを用意したいと思います。 詳細については、そのPRに関するコメントを参照してください。

$ time pip install --no-install ~/dev/git-repos/pip
DEPRECATION: --no-install and --no-download are deprecated. See https://github.com/pypa/pip/issues/906.
Processing /Users/marca/dev/git-repos/pip
  Requirement already satisfied (use --upgrade to upgrade): pip==6.1.0.dev0 from file:///Users/marca/dev/git-repos/pip in /Users/marca/dev/git-repos/pip
pip install --no-install ~/dev/git-repos/pip  3.67s user 8.12s system 7% cpu 2:45.83 total
>>> elapsed time 2m46s

うん、ほぼ3分。

おそらく主にこれが原因です：

$ du -sh .tox
177M    .tox

.toxディレクトリは、私のpipディレクトリ全体の合計.tox 7000万のうちpipです。

https://github.com/pypa/pip/pull/2535を参照してunpack_file_urlを高速化します。

マージされたPRは何もしなかったため、この問題を再開する必要があります（gh-3219を参照）。

この問題の進展はありますか？

いいえ、最終的な解決策がすぐに到着するようには見えません。 PEP516またはPEP517は、最初にsdist生成することが正しいかどうかを決定する前に、受け入れる必要があります（個人的にはそうは思いません）。

PEP516はそれを次のように要約します。

Being able to create new sdists from existing source trees isn't a thing pip does today,
and while there is a PR to do that as part of building from source, it is contentious and
lacks consensus.

おそらく最も簡単なのは、 .gitと.toxすべてをコピーするなど、最も頭の痛い動作を修正する単純なPRを送信することです（これが今日でも発生すると仮定します）。 これは多くの場合大幅なスピードアップであり、議論の余地はありません。

npmで（ソース配布の代わりに、または公開パッケージと言うべきである）ベアリポジトリからインストールするときに何をすべきか同様の問題– giturlパッケージに対してprepublishを実行します

@rgommers .gitや.toxなどのファイル/ディレクトリ名をハードコーディングする代わりに、 .gitignoreように無視するファイルとディレクトリを一覧表示するファイル.pipignoreを追加するのはどうですか。 .tox ？

これは良い考えではありません。この速度低下に対処する責任をすべてのパッケージの開発者に移しますが、これは機能しません。

npmがそれを持っているなら、それは良いはずです:) – https://docs.npmjs.com/misc/developers#keeping -files-out-of-your-package

これはまた、setuptools_scmのようなものをさらに積極的に破壊します^^-pip installを作成してフォルダーをコピーすると、すでに物事が困難になります

setuptools_scmはそれと何の関係がありますか？ いかなる種類のソースパッケージではなく、有効なリポジトリで実行する必要があり

これは良い考えではありません。この速度低下に対処する責任をすべてのパッケージの開発者に移しますが、これは機能しません。

.pipignoreに暗黙的に.git、.hgなどを含め、空の.pipignoreでこれを抑制します。

@ piotr-dobrogostソースリポジトリからのpipインストールは、pipが十分なコンテキストをコピーしないさまざまな状況で壊れます-たとえば、pypa / setuptools_scm＃138

以前は.gitなどのディレクトリを無視し、pbrなどを壊して、変更を元に戻す必要がありました。

@dstufftルートではなくgitリポジトリのサブディレクトリにある場合でも、問題が発生します^^

うーん、その破損が十分にひどい場合は、ここで物事を改善する簡単な方法はありません。 次に、ビルドPEPの1つを待機していると思います。

.git dirが存在しない状態でフォールオーバーした場合、pbrは非常に不合理なことをしているに違いありませんが、まあ…。

これに何か進展があるかどうか疑問に思いますか？ .gitや.${scm}フォルダーは面倒なだけでなく、ソースと一緒に.vagrant/含めるとさらに悪化します。

カスタマイズ可能な.pipignoreがあると、本当に苦痛を和らげるのに役立ちます。

別のデータポイントの場合。 Javascriptプロジェクトの文書化にSphinxを使用しているため、一部のプロジェクトではPythonとJavascriptが混在しています。 したがって、pipは非常に大きなnode_modulesディレクトリもコピーしているため、非常に遅くなる可能性があります。

したがって、ユースケースでは、ハードコードされた値がすべてのタイプのプロジェクトに必ずしも十分ではないことが強調されているため、 .pipignoreオプションに投票します。

人々は、SCMファイル以外のあらゆる種類のジャンクをツリーに保持します。

（さまざまなプロジェクトを追跡する方法として）パッケージのソースコードと同じディレクトリに保持するコードによって生成されたいくつかの大規模なシミュレーション（16GB +）があります。

pip install .それらを私の/ tmpにコピーします。 貧弱なパーティションは実際にはスペースを使い果たし、pipはディスクスペースエラーで失敗します。

sdistを使用することが想定されておらず、.pipignoreがインターフェイスを拡張する場合、MANIFEST.in / MANIFESTファイルを解析するためにコードを再利用するのはどうでしょうか。 インストールに必要なすべてのファイルが記述されているはずです。

良い回避策は、編集可能なインストール（ pip install -e $DIR ）を使用することのようです。

良い回避策は、編集可能なインストール（pip install -e $ DIR）を使用することのようです。

ただし、テストの場合を除いて、pypiからパッケージをインストールするユーザーが使用するものはテストされません。 （たとえば、パッケージ化されていないパッケージやモジュールは引き続き利用できます）

これがこのスレッドで以前に言及されていることを願っています。

より良い回避策は、setup.pyを使用して直接sdistまたはホイールを構築し、pipを使用して生成されたアーティファクトをインストールすることです。 そうすれば、pipはディレクトリコピーを実行しません（インストール元のファイルを取得したため）。これは、 pip install . （pip 9以降）の場合とまったく同じ結果ですが、ディレクトリコピー。

キリストのために、みんな、これはすでに何とか解決できますか？ つまり、この振る舞いは頭がおかしいというコンセンサスがあるようですが、チケットは現在3年間開いており、解決策は見当たらないのです。 pipが数分間バーフしたりハングしたりしないように、ツリーにデータを手動で出し入れする必要はありません（共有ファイルシステムで作業する必要があります）。

既存の作業を中断しない方法についてコンセンサスがない場合、 .pipignoreようなソリューションをオプトインとして提供できますか？ 私はこれを修正するためにいくつかのフープを飛び越えてもかまいません。

@ andre-merzky落ち着いてください。

私たちはこの問題を認識していますが、私たちは非常に限られたリソースを持つボランティア組織です。 そして実際には、この問題は、優先順位リストの上位に入るほど深刻な影響を与えるユーザーには影響しません。

やがて修正される予定です（そして、現時点で対処しようとしているより主要な作業、特にPEP 517は、副作用としてこの問題を解決する可能性があります）が、ボランティアに叫ぶことは役に立ちません。 早急な修正が重要であると思われる場合は、PRを確認させていただきます。ただし、PRを上げて承認されたとしても、PIP10までリリースされないことに注意してください。上記で言及した「高額な」作業の少なくとも一部を取り入れたいリリース（ボランティアのリソースの制約のために発生しない可能性がありますが、それが私たちの目標です）。 したがって、リリースされる前に置き換えられる可能性がありますが、PRを作成することを歓迎しないという意味ではありません。より大きな計画が間に合わない場合は、フォールバックになります。

@pfmoore口調で申し訳ありませんが、欲求不満が話していました...私は些細な（したがっておそらく受け入れられない）修正（＃4900）のPRを作成しました。 私はリリースサイクルであなたを聞いた、それは物事がどうなるか、私は知っている...

これにも遭遇しました：

(env) $ find node_modules/ | wc -l
140287
(env) $ time pip install .
Processing /path/to/myproject
Installing collected packages: myproject
  Running setup.py install for myproject ... done
Successfully installed myproject-1.0

real    4m35.598s
user    0m6.928s
sys 0m7.992s

リセット後：

(env) $ mv node_modules/ ../
(env) $ time pip install .
Processing /path/to/myproject
Installing collected packages: myproject
  Running setup.py install for myproject ... done
Successfully installed myproject-1.0

real    0m0.899s
user    0m0.496s
sys 0m0.120s

問題に関する最新のプロファイリングレポートはどこにありますか？

ここでは変更はありません。 現在でも、pipはパッケージ全体を一時的なビルドディレクトリにコピーしています。

このディレクトリはメモリ内にありますか？

いいえ、ディスクに書き込まれます-これは共有ファイルシステムで特に苦痛になります...

少なくとも/tmpまたは/dev/shmますか？ https://stackoverflow.com/questions/9745281/tmp-vs-dev-shm-for-temp-file-storage-on-linux tmpfsが使用されていないことを検出し、作成を提案できますか？

/tmpます。 stdlib tempfileに依存します。

PEP 517を実装すると、これが解決されます。

私はpipの最新の開発者バージョンでこれに遭遇しています-PEP517サポートがpip19に追加されたと思ったので、これはまだ発生しているはずですか？

私の場合、多くのリモートとブランチがあるプロジェクト（astropy）で作業しているため、.gitディレクトリは1.8Gbであり、これを一時ディレクトリにコピーするのに数分かかります。 最初にソースディストリビューションを構築してから、舞台裏でそこからホイールを構築する方が理にかなっているようです。

この問題のために、私たちはまだかなりひどい傷を負っています。 コードと実験データ（大きい）を同じディレクトリに保持できないことをユーザーに伝えるのは非常に困難です。これは非常に直感的ではありません。 私たち自身のシステムでは、 .pipignoreパッチを使用していますが、サポートしているシステムの大部分にそれを展開する機能はありません...：/

今日もこのhttps://github.com/pypa/pip/issues/2195#issuecomment-351258913に遭遇します。 それはまだ起こっています。

(venv) (venv) pip --version
pip 19.1.1 from /application/venv/lib/python2.7/site-packages/pip (python 2.7)

PEP 517を実装すると、これが解決されます。

ナレーター：そうではありませんでした。

これを修正するには、sdistを介してインストールする必要があります。前回説明したときに、実際のソースディレクトリを（明らかに）必要とするツールを使用している人々から多くの反発がありました。 個人的には、 build_sdist build_wheelを実行したときにbuild_wheelを実行したときに得られるのと同じ結果が得られないビルドプロセスを、弾丸を噛んで非推奨にする必要があると思います。しかし、現時点では、その提案を自分で支持する時間やエネルギーがありません。

これを修正するには、sdist経由でインストールする必要があります

実際には、いいえ-＃4900は、下位互換性のある方法で小さなコードで問題を解決する実装を提供していません。 他の問題は解決しないかもしれませんが、このチケットの年齢を考えると、そのアプローチを再考するようにお願いしたいと思います。

これを修正するには、sdistを介してインストールする必要があります。前回説明したときに、実際のソースディレクトリを（明らかに）必要とするツールを使用している人々から多くの反発がありました。 個人的には、build_sdistを実行した後、build_wheelを実行したときと同じ結果が得られないビルドプロセスを廃止する必要があると思いますが、その提案を自分で支持する時間やエネルギーがありません。この時点で。

インプレースビルドを気にかけ、「常にsdistルートを経由する必要がある」ことを嫌った人として：私はずっと前に「gosdistルート」と和解しました。

この問題に遭遇した場合、この問題は_非常に_苦痛であり、「デフォルトですべてをコピーする」ことはほとんど意味がありません。 だから弾丸を噛むのに+10。

これを修正するには、sdist経由でインストールする必要があります

間違って、PEP517で切り替えると思っていました。

私はここであなたに完全に同意します。

IIRCを実行することもできましたが、sdistを介したインストールが受け入れられるかどうかについての議論は、当時追加するには余計な論争でした。コピーしてホイールを作成することはまだオプションだったので、ストレスを軽減しました。コース ：-）

まだsdist経由でビルドに切り替えたいのですが、今は自分で切り替える時間がありません。

回避策：浅いクローンを使用します（必要に応じて深さを変更します）：

cd d:\code
git clone --depth=100 https://github.com/PROJECT/PROJECT.git d:/code/shallow-PROJECT
move d:\code\PROJECT d:\code\PROJECT-bloated
move d:\code\shallow-PROJECT d:\code\PROJECT

繰り返して要約するには：

• ピップメンテナは、これがユーザーにとって良い経験ではないことに同意します。 pip自身の開発プロセスがこの問題にぶつかります。
• これが発生する理由は、ビルドがソース外のものに依存しないようにするために、pipがソースディレクトリを一時ディレクトリにコピーするためです。
• この問題を解決する方法は、pipの動作を変更して、ツリー内にソースディストリビューションを構築し、一時ディレクトリにソースディストリビューションを解凍して、そこからバイナリを構築することです。

現在、このルートを使用すると、ユーザー向けのpipの構築メカニズムに関する他の多くのユーザビリティの問題も修正されます。

私は、pipのビルドロジックをリファクタリングするための自発的なプロジェクトを開始しました。 私はリファクタリング作業の一環としてこの問題に取り組むつもりはありませんが、この問題を修正しようとする傾向がある人を喜んで支援します-修正はpipのビルドロジックにかなり関与しますが、そうではありませんこれは最も単純なコードではなく、実装中にのみ気付くトリッキーなエッジケースがあるかもしれません。

ああ、そしてこれに対するバンドエイドの回避策として、＃6770で追加され、pip 19.3はコピー時に.noxおよび.toxディレクトリを除外します。 これにより、かなりの数のユーザーにとって、これらのインストールにかかる時間が短縮されます。

これでは、大きな.gitまたはbuildディレクトリの問題は解決されません。これは、上記のコメントで詳しく説明したアプローチで解決されるものです。 :)

これでは、大きな.gitまたはbuildディレクトリの問題は解決されません。これは、上記のコメントで詳しく説明したアプローチで解決されるものです。 :)

.gitに依存するツールがいくつかあることは知っていますが、 buildコピーに依存している人はいますか？ 無視されたdirに追加するとよいでしょう。同意する場合は、PRを送信してください。

これはまだ調査中ですか？ pip install .間に、複数ギガバイトのgitが無視されたデバッグデータダンプがコピーされるのを見るのは非常に痛い驚きです。

はい、＃7555のようなリンクされた問題を見てください。

インストール元のディレクトリにはおそらく10MBのPythonコードが含まれているため、この問題は引き続き発生しますが、多くのjsonデータファイルと.gitます。

これは＃7882（ローカルディレクトリを適切に構築する）によって解決されるはずです。

現在（＃7951に従って）pipのベータリリースであるpip20.1b1を公開しています。 このリリースには、この問題の解決策を実装した＃7882が含まれています。

この号の参加者がベータ版をテストし、新しいバグをチェックすることで私たちを助けてくれることを願っています。 火曜日のメイン20.1リリースの前に、潜在的な問題を特定して解決したいと思います。

また、「イェーイ、今はうまく機能している！」という肯定的なフィードバックを歓迎します。 同様に、課題トラッカーは通常「課題」でいっぱいなので。 :)

かなり良いと思います。

古い： noglob pip3 install . 3.76s user 2.51s system 12% cpu 50.245 total

新規： noglob pip3 install . 3.40s user 0.70s system 42% cpu 9.764 total

私にとっては素晴らしく/速く動作します！ ：+1：

» pip --version
pip 20.0.2 
» time pip install .
noglob pip install .  8.03s user 18.47s system 25% cpu 1:44.84 total

» pip --version
pip 20.1b1 
» time pip install .
noglob pip install .  3.69s user 0.31s system 92% cpu 4.307 total

約2分から4秒に短縮しました。ありがとうございました。

肯定的な報告をありがとう@ PythonCoderAS @ astrofrog @klamann！ :)

残念ながら、インプレースビルド（＃7555で追跡されています）の実装には多くの問題があります。つまり、今のところ、＃7882を元に戻す必要があります。 その結果、この問題は再び問題になるため、再開します。 長期的には、インプレースビルドで解決された問題に対処するソリューションが必要ですが、現在のソリューションが持っていた他のワークフローに影響を与えることはありません。

これによりご迷惑をおかけしますことをお詫び申し上げます。

残念ながら、インプレースビルドの実装には多くの問題がありました

@pradyunsgアップデートしてくれてありがとう。 用語に関するいくつかのフィードバック（参考までに、無視してください）：この文とgh-7555は、pipがインプレースビルドを行わないため、私を混乱させました。 インプレースビルドが常に意味するのは、 python setup.py build_ext --inplace （またはpython setup.py develop ）です。

ここで、意味を「tmpdirにコピーせずにビルドする」に変更しました。 拡張モジュールはまだインプレースではなく、通常は簡単にクリーンアップできるbuild/ディレクトリになります。 たとえば、gh-7555でもう少し明確にするとよいでしょう。

それはもともと私の言葉遣いでした。 混乱して申し訳ありませんが、setuptoolsが「インプレース」という用語を別の意味で使用していることに気づいていませんでした（そして、その用語がsetuptoolsの外部でどのように適用されるかはまだよくわかりません）。 将来、もっと中立的な用語を見つけることができるかどうかを確認します（ただし、手に負えないのですが、何がわかりません-提案はありがたく受け入れられました😉）

@pfmooreに感謝します。 用語についての混乱は時々お互いを通り越して話すことになるかもしれないので、私はそれを指摘したいと思いました。

そして、その用語がsetuptoolsの外でどのように適用されるのかまだよくわかりません

CMakeやscikit-buildのようなツールの場合、それは同じことを意味すると思います。実際にはインプレースで、バイナリはソースの隣に配置されます。

一方、「編集可能なインストール」は（私が信じる）ここで発明されたものであり、ちょっと「ピップが認識しているインプレース」を意味します。

手に負えないが、私は何がわからない-提案はありがたいことに受け入れられた

たぶん「ローカルビルド」（vs.現在の「tmpdirにコピーしてビルド」）？

一方、「編集可能なインストール」は（私が信じる）ここで発明されたものであり、ちょっと「ピップが認識しているインプレース」を意味します。

最近、編集可能なインストールの意味について長い議論がありましたが、実際には、ピップに関してはmachine localの線に沿った場所に着陸したと思います。 しかし、pipはローカルマシンのどこでどのように動作するかを認識しておらず、それを定義して処理するためのビルドバックエンドジョブです。

«ツリー内ビルド»（«ツリー内PEP 517バックエンド»と同様）または«ソースディレクトリでのビルド»を試すことができます。

私の質問は、なぜこの機能をオプションにできないので、問題は発生しないが、引数などで有効にできるのかということです。

編集可能なインストールがオプションではない場合、この回避策に頭を悩ませようとしています。 ありますか？

回避策は、ホイールをビルドし（ビルドバックエンドを直接使用して）、pipをポイントしてインストールすることです。

この機能をオプションにできないのはなぜですか。問題は発生しませんが、引数などで有効にできます。

できる。 変更を元に戻す理由は、オプトアウトや変更に関するフィードバックを受け取る期間がなかったためです。 これを容易にするための新しいフラグ（--use-featureおよび--deprecated-feature）がありますが、誰かがこのコンテキストで機能を再実装/再導入する必要があります。

大まかに言って、ここでやりたいことは次のとおりです。

• オプトインとして--use-feature = in-tree-buildを追加します。
• それ以降のリリースでは、オプトアウトとして--deprecated-feature = out-of-tree-buildを使用してデフォルトを切り替え、-use-feature = in-tree-buildのユーザーにそれを削除するようにプッシュします。
• 後続のリリースで両方のオプションを削除します。

回避策は、ホイールをビルドし（ビルドバックエンドを直接使用して）、pipをポイントしてインストールすることです。

私は余分なビルドステップなしで考えていました。 しかし、Pythonが最初からMakefileに相当するものなしで逃げることができるとは思ってもみなかったと思います。