Pipenv: ロックが遅い（そして冗長なダウンロードを実行する）

@colllinサーバーに接続するpipコマンド（ pip search （私は思う）など）も遅いかどうかを確認しましたか？

同様の動作が見られますが、これは既知の問題であり、ネットワークに依存します。 何らかの理由で、職場のネットワークからpypi.orgにアクセスするのは非常に遅いですが、通常、自宅のネットワークからは高速です。 ロックは内部で多くのpipトランザクションを実行すると思うので、サーバーへのアクセスが遅いと操作が大幅に遅くなります。

編集：解決すべきサブ依存関係がたくさんある可能性もあります-一度作成された環境の大きさ（たとえば、pipfile内のトップレベルパッケージの数、 pip listによって返されるパッケージの数など）環境がブートストラップされたら）？

思いやりのある対応ありがとうございます。

pip searchは私にとって特に速くも遅くもありません... 〜1秒？

ドメイン知識が不足していることをお許しください。本当に検索をピップする必要がありますか？ すべてをインストールするだけではありませんか？ すでにインストールされているものを書き留めるだけではいけませんか？ または...とにかくロックファイルの存在を保証するので、パッケージをインストールするとき、またはそれ以前にこれ

私は推測しています... pipenvはボンネットの下でpipを使用していますか？ したがって、インストールプロセスはブラックボックスであり、〜pip search〜独自のpipクエリを実行せずに、何がインストールされたか、またはインストールされるかについての依存関係グラフを知ることはできませんか？

編集：1つのトップレベルパッケージがあり、この特定のリポジトリではpip listによって返される最大65のパッケージがあります。

私はプロジェクトの貢献者ではなく、現時点ではすべての詳細を知りませんが、ロックフェーズでは、すべての依存関係が解決され、固定されると理解しています。 したがって、依存関係が最大65のトップレベルパッケージが1つある場合、その最初のパッケージのすべての依存関係が（再帰的に）検出されるのはロックフェーズであり、依存関係ツリーを使用して、インストールする必要のあるパッケージを解決します。 （おそらく）どのような大まかな順序でインストールする必要があります。最後の部分についてはよくわかりません。

ロックファイルが存在しない状態でPipfileからpipinstallを実行すると、パッケージをvenvにインストールする--deploy場合と同様に、より高速になるオプションを--no-lockオプション。 前者の場合、ロックファイルが古くなっているとエラーが発生します。後者の場合、最上位パッケージ（宣言された環境）とすべてのパッケージの実際にインストールされた（ロックされた）環境の論理分割が失われます。 少なくともこれは私がそれを理解する方法です。

pipenvが内部でpipを使用するかどうか（使用するかどうかはわかります）でも、パッケージの依存関係などに関する情報をpypiサーバーから取得する必要があるため、pip検索に関する私の質問はより高速またはpypiサーバーへのパスを遅くすることは、pipenvがその処理を実行するメカニズムについての直接的な意味よりも重要です。

興味深い実験は、pipenvで依存関係ツリーをロックし、 pip install -r requirements.txtを使用して新しいvenvに要件をインストールするために必要な時間を比較することかもしれません。 依存関係の解決フェーズでは、かなり似たようなことをする必要があると思います。

冗長なダウンロードが発生していることをどこかで確認しましたか？ そうだと思いますが、それを証明することは本当に役に立ちます

参考までに、 pip install -r requirements.txtを依存関係グラフのロックにかかる時間と比較しても、比較のポイントとしては有益ではありません。 Pipは実際にはリゾルバーを_持っていません_、本当の意味ではありません。 違いを説明できると思います。 pipがrequirements.txtインストールすると、次の基本的なプロセスに従います。

• リストされている最初の要件を見つける
  
  
  
  • そのすべての依存関係を見つける
  
  
  • それらすべてをインストールします
  
  
• リストされている2番目の要件を見つける
  
  
  
  • そのすべての依存関係を見つける
  
  
  • それらすべてをインストールします
  
  
• リストされている3番目の要件を見つける
  
  
  
  • そのすべての依存関係を見つける
  
  
  • それらすべてをインストールします
  
  

_package1_の依存関係が_package3_の依存関係と競合するかどうかは、pipが実際には気にしないため、これは非常に高速であることがわかります。最後に_package 3_にインストールしただけなので、これが得られます。

Pipenvは別のプロセスに従います。環境を構築する前に、指定した依存関係の_すべて_を満たすことを試みる解像度グラフを計算します。 つまり、実際のインストールプロセスを開始する前に、パッケージのダウンロード、比較、場合によっては_building_パッケージを開始して、最終的に環境がどのようになるかを判断する必要があります（これについては、多くのブログ投稿があります）。 Pythonの場合なので、ここでは詳しく説明しません）。

その解決プロセスの各ステップは、ハッシュを必要とすることにより、計算コストが高くなります。これはベストプラクティスです。 受け取ったパッケージを受け取った後にハッシュし、PyPIが期待すべきと言ったハッシュと比較し、将来、同じ環境を構築したい人がそうできるように、それらのハッシュをロックファイルに保存します。それらが構築するパッケージが最初に使用したものと同じであることの契約上の保証。

Pip検索は、これらのいずれに対しても不十分なベンチマークです。実際、pipのツールはいずれも、この作業を行うための不十分なベンチマークです。各部分にpipを使用しますが、協調して、多くの依存関係にわたってまとめて、形成および管理します。環境とグラフは、pipenvの値が追加される場所です。

明確化の1つのポイント-完全な依存関係グラフを解決すると、インストールの順序は重要ではなくなります。 内部的には、とにかくすべてのインストールに実際に--no-depsを渡します。

ちょっとした補足として、pip検索は現在非推奨のXMLRPCインターフェースに依存する唯一のpipのツールであり、キャッシュできず、非常に低速です。 他のどの操作よりも常に遅くなります。

numpyをロックする（そして他には何もしない）のは私のマシンでは220秒かかります（以下を参照）。 ほとんどの時間は200MBを超えるデータのダウンロードに費やされているようですが、numpyソース全体が4 MBであることを考えると、これは非常に不可解です。 明らかにそれが瞬時であったとしても、実際の処理はまだ25秒あり、それでもいくつかのハッシュを計算するには過剰に思えます。 Pipenv.lockを削除した後でも、その後のロックには5秒かかります。

11:46 ~/Co/Ce/torchdft time pipenv install
Creating a virtualenv for this project…
Using /usr/local/Cellar/pipenv/2018.5.18/libexec/bin/python3.6 (3.6.5) to create virtualenv…
⠋Already using interpreter /usr/local/Cellar/pipenv/2018.5.18/libexec/bin/python3.6
Using real prefix '/usr/local/Cellar/python/3.6.5/Frameworks/Python.framework/Versions/3.6'
New python executable in /Users/hermann/.local/share/virtualenvs/torchdft-mABBUp_t/bin/python3.6
Also creating executable in /Users/hermann/.local/share/virtualenvs/torchdft-mABBUp_t/bin/python
Installing setuptools, pip, wheel...done.

Virtualenv location: /Users/hermann/.local/share/virtualenvs/torchdft-mABBUp_t
Creating a Pipfile for this project…
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Updated Pipfile.lock (ca72e7)!
Installing dependencies from Pipfile.lock (ca72e7)…
  🐍   ▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉▉ 0/0 — 00:00:00
To activate this project's virtualenv, run the following:
 $ pipenv shell
        7.81 real         6.39 user         1.64 sys
11:46 ~/Co/Ce/torchdft time pipenv install numpy --skip-lock
Installing numpy…
Collecting numpy
  Using cached https://files.pythonhosted.org/packages/f6/cd/b2c50b5190b66c711c23ef23c41d450297eb5a54d2033f8dcb3b8b13ac85/numpy-1.14.5-cp36-cp36m-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl
Installing collected packages: numpy
Successfully installed numpy-1.14.5

Adding numpy to Pipfile's [packages]…
        4.97 real         2.88 user         1.81 sys
11:46 ~/Co/Ce/torchdft time pipenv lock --verbose
Locking [dev-packages] dependencies…
Using pip: -i https://pypi.org/simple

                          ROUND 1                           
Current constraints:

Finding the best candidates:

Finding secondary dependencies:
------------------------------------------------------------
Result of round 1: stable, done

Locking [packages] dependencies…
Using pip: -i https://pypi.org/simple

                          ROUND 1                           
Current constraints:
  numpy

Finding the best candidates:
  found candidate numpy==1.14.5 (constraint was <any>)

Finding secondary dependencies:
  numpy==1.14.5 not in cache, need to check index
  numpy==1.14.5             requires -
------------------------------------------------------------
Result of round 1: stable, done

Updated Pipfile.lock (4fccdf)!
      219.24 real        25.14 user         5.77 sys

Numpyは今ではかなり速くなっているはずです（実際、私はあなたの例をテストケースとして使用しています！）。 最近のテストの時点で、VMのコールドキャッシュで約30秒でテストを実行しました。

最新リリースでの改善点を確認できますか？

私にとっても大幅に改善されました。 私は今、非常に高速な接続を使用していて、14秒という低さでしたが、ダウンロードが30 MB / sで行われたのはそのときでした。 numpyのソースコードの単一のコピー以外に何がダウンロードされていますか？

冗長ホイールをダウンロードしていると思います（わかりません）。 私たちはすでに状況を評価しています。

feの変更をアンインストールして、Pipfile.lockを大幅に変更しましたが、別のマシンにデプロイするとフリーズします。 これに対する特定の修正はありますか？

ロックファイルを手動で編集することはお勧めしません。 より多くの情報がなければ、助けることは不可能です。 別号を開いてください。

pipenvロックのパフォーマンスをベンチマークする場合は、依存関係にpytmxを追加してみてください...
pipenvロックは以前は1時間以上かかりましたが（インターネットはかなり遅いです）、pytmxを削除した後、約5分になり、ついにpipenvがより使いやすくなりました。
pytmxは大きなモノリシックライブラリであり、opengl / pygameやその他の関連するものに依存しているため、大きなパッケージであることは知っていますが、パッケージがいくら大きくても、pipenvロックに1時間かかることはありません。

私にとっては1時間もかかりません

$ cat Pipfile
[packages]
pytmx = "*"

$ time pipenv lock --clear
Locking [dev-packages] dependencies...
Locking [packages] dependencies...
Updated Pipfile.lock (eb50ab)!

real    0m2.827s
user    0m2.287s
sys 0m0.390s

また、PyTMXはPyPIで20kb未満であり、依存関係は6つ（非常に小さい）に1つしかないため、ネットワークは問題になりません。 あなたの環境で何か他のことが起こっている可能性があります。

確かに、pygameなどに明示的に依存していないと思っていたよりも小さいので、なぜそんなに時間がかかったのかわかりません！
私はより多くの情報を見つけようとしますが、私はトップのCPUとSSDを持っているので、問題はまだ私たちの遅いインターネットに関連していると思います

@techalchemyファイルを手動で編集しませんでした。 pipenv uninstall package_nameを使用して多くの依存関係をアンインストールし、その後サーバーで実行しました。 それは非常に長い間ロック状態にとどまりました。

私は暗闇の中でランダムなショットでこの議論にエネルギーを費やすことには興味がありません。 再現可能なテストケースを提供してください。

これが再現可能なテストケースであることを願っています
https://github.com/Mathspy/tic-tac-toe-NN/tree/ab6731d216c66f5e09a4dabbe383df6dc745ba18

しようとしています
pipenv install
このロックレスリポジトリでは、これまでに700MB以上をダウンロードして表示されています
Locking [packages] dependencies...

少しあきらめて、修正されるまで--skip-lock再実行します

lockは非常に遅く、 files.pythonhosted.orgから大量のデータをダウンロードしたことに気付きました。 scipy flaskなどに依存する小さなプロジェクトでは800MB以上です。

そこで、 files.pythonhosted.orgに対して行われたリクエストをスニッフィングしたところ、pipまたはpipenvが完全に不要なダウンロードを実行していたため、 lockが非常に遅くなっていることがわかりました。

たとえば、同じバージョンのnumpyが完全に数回ダウンロードされていました。 そして、私はMacを使用していましたが、Windows / Linux用のホイールをダウンロードしました。

私のセットアップ：

$ pipenv --version
pipenv, version 2018.05.18

$ pip -V
pip 18.0 from /usr/local/lib/python2.7/site-packages/pip (python 2.7)

ここでのデバッグに役立つ追加のPipfileはありますか？

おそらく@AlJohri 、実行中のプロセス/ロック/ ioに関する情報も役立ちます

すでに約5分間ここで立ち往生しています。 最初は、それはある種のpipインストールの問題である可能性があると考え、Homebrewを介してすべてを新しく再インストールしましたが、それでも同じ問題です。 なぜ何かアイデアはありますか？

約6〜7分後にようやく終了しました。 PythonとPipenvはかなり新しいので、デバッグに必要なファイルを見つける場所について少し助けていただければ幸いです。 :)

これは、新しいPythonライブラリをインストールしたり、既存のPythonライブラリをアップグレードしたりするのが怖いという点でかなり悪いです。

クリエイターからの講演を見て、 pipenvを使うことにしました。 しかし、それは遅すぎます。

洞察に満ちたフィードバックをありがとう。

@techalchemy何か助けて、これを修正するために私ができることがあれば。 貢献できてとてもうれしいです。

lockは非常に遅く、 files.pythonhosted.orgから大量のデータをダウンロードしたことに気付きました。 scipy flaskなどに依存する小さなプロジェクトでは800MB以上です。

決定的な証拠ではありませんが、 scipyが非常に長いpipenvロック時間と相関しているのではないかと疑っています。

時々本当に苦痛です、私はPyPDF2とtextractをインストールしています。 pipenvはロックするのに約10分かかりました。

pipenvの遅さは、私たちの開発プロセスを本当に妨げます。 この問題が解決するまで、pip + virtualenvを使用することをお勧めします。

これに関するニュースはありますか？ 助ける方法はありますか？
https://github.com/pypa/pipenv/issues/1914の複製

/編集：ところで、なぜpipenv installはロックファイルのバージョンを更新するのですか？ o.Òロックがタイムアウトした後に実行しました。新しいロックファイルを見ると、パンダが0.23.4から0.24.0に、numpyが0.16.0から0.16.1に更新されていることがわかります。私がpipenv updateをしなければ、それが起こるとは思わない...

インストールが速く、ロックが遅いので、 Installation Succeededメッセージが表示されたらすぐに、他の何かをインストールしたい場合を除いて、作業を続行できます...

...またはロックファイルをリポジトリにプッシュする必要があります。

lockがすでに別のコマンドであることを確認して、 installとにかくロックを実行する必要がありますか？ その間、 installオプションの説明では、ロックも行われることを指定する必要があり、おそらく--skip-lock推奨することさえあります。

また、この問題を固定するのはどうですか？

Pipenvは本当に素晴らしいツールで、以前はそれをお勧めしていましたが、8つのモジュールを含むプロジェクトではロックできません...タイムアウトするだけです。 この問題を解決することに関心はないようで、それは非常に苛立たしいことです。 pypyからダウンロードしなくても依存関係を取得できると読みましたが、これはこの問題の回避策ですか？ ここでそのオプションについての話は見られません。 現時点では、ツールは私の目的には使用できません。

pexpect.exceptions.TIMEOUT: <pexpect.popen_spawn.PopenSpawn object at 0x10e12e400> searcher: searcher_re: 0: re.compile('\n') <pexpect.popen_spawn.PopenSpawn object at 0x10e12e400> searcher: searcher_re: 0: re.compile('\n') pipenv lock -r 87.22s user 18.57s system 11% cpu 15:02.77 total

これがこのプロジェクトの主な優先事項ではないのはなぜですか？ Pipenvは非常に遅いので、ほとんど使用できません。 いくつかの珍しい側面のユースケースだけでなく、常に非常に遅いです。

内部で何が起こっているのかをあまり知らずに、依存関係グラフのローカルキャッシュでこれをうまく解決できるのではないかと考えていました。

考えてみてください。パッケージx-1.2.3がy>=3.4に依存している場合、パッケージを1つずつダウンロードして拡張し、依存関係を確認する際に現在行われている多くの作業をローカルで実行できます。 。 lockフェーズは、次のように単純になります。

• Pipfileをキャッシュと比較し、必要なものがすべて揃っていることを確認します。
• そうでない場合は、新しいものをダウンロードして、そこで依存関係を計算します
  
  
  
  • 変更をキャッシュする
  
  
• インストール。

いずれの場合も、最初は遅いかもしれませんが、その後のロックは痛みがありませんね。

小さなプロジェクトでは、pipの代わりにpipenvを使用することにしました。 私が最初にしたことはpipenv install -r requirements.txt 。 現在、約10分間依存関係をロックしています。 したがって、ピップに戻ります。

皆さん、この問題は多くのユーザーに負担をかけています。 私はそれに迅速に対処することを提案します。

私の場合、依存関係をサーバーにインストールすると、サーバーが何時間もハングします。 1GBのRAMを搭載したAWSEC2インスタンスt2.microを使用しています。 これだけのRAMは、依存関係がほとんどない単一のアプリケーションには十分ですが、インストールにはすべてのメモリが必要であり、サーバーを再起動して動作させる方法は1つしかありません。

この問題は非常に長い間保留されており、修正は行われていません。 解決せずに複数の問題が解決されているのがわかります。

そのような素晴らしいツールは無視されています。 この問題は解決されないので、購読を解除します。 condaのようなものに固執するか、virtualenvを使用して手動で実行します。

https://github.com/sdispater/poetryを試してみようと思い

管理者はこのスレッドをコメントに近づけることができますか？ ディスカッションに役立つ追加コンテンツが追加されていないようです。

問題の修正に向けた作業を追跡するチケットを購読できれば幸いです。

ありがとう！

このツールを使用していて、このスレッドに不満を言っている人の99％はプログラマーだと思います。 泣き言を言う代わりに、口の中に時間を置いてPRを提出してください。

こんにちは@idvorkin 、

私は一度試しまし
些細な修正のマージを達成するのに数週間かかりました。
ディスカッションの量を実際の修正サイズと比較するだけです。

私は間違いなく、このプロジェクトにこれ以上の修正を提出したくありません。

したがって、あなたのアドバイスはあなたが想定できるほど実行可能ではありません。

@Jamimは多くのユーザーを代表して（そして私は管理者もそうだと思います）、あなたの貢献に感謝します。 私はあなたのPRを読みました、そして私は欲求不満に共感することができました。 ただし、これについては@techalchemyに同意する必要があります。

もちろん、私たちは私たちが維持している図書館に関心を持っていますが、フレージングは​​おそらく前向きな相互作用を持つための最も効果的な方法ではないことをお勧めします。

私は管理者に会ったことがありませんが、彼らが私のようなものであれば（そしておそらくあなた）、彼らは忙しい生活を送っている人間であり、このプロジェクトに費やすエネルギーを得る前から、人生はコミットメントに満ちています。

同様に、あなた（または他の誰か）がパフォーマンスの問題を修正した場合、開発、テスト、マージ、または必要に応じて（そして私はそれがそうなるとは非常に疑わしい）フォークの作成を支援する多くの人々がいるでしょう。

このプロジェクトの開発者がこれに費やしている時間に感謝しますが、このプロジェクトはまだREADME.mdのユーザーの証言のすぐ上で本番環境に対応していないことを太字で警告する必要があります。現在は人々がこの遅いロックについて知り、それを使用できないことを理解するまで、現在のpip / virtualenvスタックをpipenvに置き換えるために貴重な時間を費やすように誤解を招く人々。

彼らがこの遅いロックについて知り、彼らがそれを使用できないことを理解するまで。

本当に非常に遅いのでスピードを上げることができてとてもうれしいですが、そのような誇張は必要ありません。

私は毎日pipenvをうまく使っています。 それが提供するワークフローの改善は、時折の速度低下を大幅に上回ります。 たとえばスクリプトを実行するのとは対照的に、ロックは私がいつも行うことではありません。

実際に使用できないと感じるような問題になることをどのくらいの頻度でロックしますか？ ：open_mouth：

@bochecha私の声明はあなたの意見では誇張かもしれませんが、それは私の経験に基づく事実です、私は何人かの同僚からpipenvについて聞いた、今日私は古いプロジェクトを更新しようとした、その依存関係を更新しようとした、など私はpip / virtualenvから更新できると思った更新プロセスの一部としてのpipenv。 依存関係を更新し、それがどのように機能するかを確認し、必要に応じてコードの一部を更新してから、別の依存関係を更新する必要がありました。 pipenv install <something>を実行するたびに、途方もなく長い時間を待たなければなりませんPipfileとPipfile.lockを削除して、pip / virtualenvワークフローに戻りました。 私は詩を試してみたくなりましたが、もう1時間危険を冒すことはできませんでした。

たとえば、このことはJSコミュニティで発生しますが、Pythonコミュニティでは発生しないと思います。コミュニティではこの種の問題は発生しないため、回避する必要があります。 README.md免責事項は回避できます。この不便さなので、コメントで提案しました。 今日の私の時間を節約でき、他の新規参入者の時間を節約でき、彼らはこのプロジェクトで悪い経験をすることはないので、将来の潜在的なユーザーとして留まることができると思います。

私はサッサンにちょっと同意します。 誰もが同じようにこの問題の影響を受けているわけではありませんが、私たちの何人かはかなりひどい影響を受けました。 私は完全に機能していない、または本番環境に対応していないオープンソースプロジェクトを作成しました。その場合は免責事項を記載しているので、問題が発生する準備ができていなくても時間を無駄にすることはありません。

私はこのプロジェクトに携わっている人々に腹を立てていませんが、それについて公に話をした人にちょっと腹を立てており、免責事項がない優れたツールとして販売しています。 その結果、長期的に時間を節約したいと思って、ツールを機能させるために貴重な時間をかなり無駄にしましたが、pipenvが機能しなかったため、pipと自分のスクリプトに戻る必要がありました。私の時間と帯域幅に制約のある環境で。

pipenvinstallを実行するたびに

プロジェクトをpipenvに移動しようとしたときに、既存のプロジェクトから1回だけロック/インストールするpipenv install -r requirements.txtについて知っていましたか？ そうでない場合、問題はドキュメントの1つである可能性がありますか？

何よりもまず、pipenvがpip / virtualenvワークフローの優れた代替品になると確信しています。私たち全員がそれを必要としていることを知っていると思います。また、pipenvが本番環境に対応できる日は、多くの人々/プロジェクトにとって大きな助けになると思います。

@bochechaで説明したように、新しいバージョンのパッケージをインストールし、いくつかの作業を行ってから次のパッケージに進む必要がありました。おそらく、このプロセスをpipで実行してから、pipenvに移行した場合、問題にまったく気付かないでしょう。しかし、私は最初にpipenvに移行し、次にパッケージを1つずつ更新しましたが、それは本当に面倒でした。 それがあなたのユースケースで機能することを嬉しく思いますが、私のような多くの人々にとっては機能しないと確信しています（上記のコメントを見てください）。 README.mdに記載する必要があります。少なくとも、「各ロックには時間がかかる可能性があるため、ユースケースに多数のパッケージのインストール/削除が含まれている場合は、この問題が発生するまで、pipenvの使用を避ける必要があります。解決済み」（ここでも太字で、証言に加えて）誰かが影響を受ける前に問題を発表すると、誰もが感謝します。問題が他の人に影響を及ぼし、警告しなかった場合、誰もが怒ります。

同意しました。 私は詩を調べ始めましたが、pipenvを再度使用する代わりに、プロジェクトごとにOSに別のユーザーを追加しました。 デフォルト設定でのカジュアルなユースケースでうまく機能しない場合は、 imhoが壊れてい
とても便利なツールです！ 私にとってそれを非常に役に立たないものにしているのはこの1つだけです。 そして悲しいことに、私は貢献する時間がほとんどありません：|

確かに、開発セッションの途中で複数のインストールを実行する必要がある場合、ロックを待つのは面倒ですが、これは管理できます。

重要なことは、ローカルの変更をリポジトリにプッシュする前にロックファイルが生成されることです。 私は開発セッション中に—skip-lockフラグを慎重に使用し、コミットする前に最後にpipenv lock 1回使用します。

プロジェクトをありがとう。 しかし、
ロックはverrrrrrrrrrrrrrrrrrrrrrrrrrrrrryslowwwwwwwwwwwwwwwwwwwwwwwwwwwwwです。

PIP_NO_CACHE_DIR=off
このenvは、pipパッケージキャッシュがすでにインストールされている場合、ロックをより高速にします。

こんにちは@yssourceと皆さん、

プロジェクトをありがとう。 しかし、
ロックはverrrrrrrrrrrrrrrrrrrrrrrrrrrrrryslowwwwwwwwwwwwwwwwwwwwwwwwwwwwwです。

このプロジェクトは死んでいるようです。速度の問題を解消したい場合は、大幅に高速なPoetryへの移行を検討してください。

@Jamim 、詩を提案してくれてありがとう。 個人的には、どういうわけか出会えませんでした。 そのreadmeを読んだ後、試してみる価値があるようです。 Pipenvに比べていくつかの利点もリストされています（https://github.com/sdispater/poetry/#what-about-pipenv）。

そうは言っても、プロジェクトが死んでいることはひどく誇張されており、もし私がpipenvの作者の立場にあったとしたら、それは無礼だと思うでしょう。 著者は昨日、問題のセクションで返信しました。 おそらく修正が難しいため、このロックの問題が見落とされているだけです。

記録として、Poetryはパフォーマンスの問題にも悩まされています。
https://github.com/sdispater/poetry/issues/338

私はすべてのプロジェクトで同じ問題を抱えています。
原因はピリントのようです。
Pipenv（pip）は正常にインストールできますが、ロックには永遠に時間がかかります。
pipenv, version 2018.11.26

djbrown@DESKTOP-65P6D75:~$ mkdir test
djbrown@DESKTOP-65P6D75:~$ cd test
djbrown@DESKTOP-65P6D75:~/test$ pipenv install --dev pylint --verbose
Creating a virtualenv for this project…
Pipfile: /home/djbrown/test/Pipfile
Using /usr/bin/python3 (3.6.9) to create virtualenv…
⠸ Creating virtual environment...Already using interpreter /usr/bin/python3
Using base prefix '/usr'
New python executable in /home/djbrown/.local/share/virtualenvs/test-PW-auWy_/bin/python3
Also creating executable in /home/djbrown/.local/share/virtualenvs/test-PW-auWy_/bin/python
Installing setuptools, pip, wheel...done.

✔ Successfully created virtual environment!
Virtualenv location: /home/djbrown/.local/share/virtualenvs/test-PW-auWy_
Creating a Pipfile for this project…
Installing pylint…
⠋ Installing...Installing 'pylint'
$ ['/home/djbrown/.local/share/virtualenvs/test-PW-auWy_/bin/pip', 'install', '--verbose', '--upgrade', 'pylint', '-i', 'https://pypi.org/simple']
Adding pylint to Pipfile's [dev-packages]…
✔ Installation Succeeded
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
⠇ Locking...

私はpipenvについてたくさん聞いて、今日それを試しました、
ロックも私にとっては非常に遅いです。 すでに2分ほど経っていますが、まだロックされています。
ダウンロードはかなり高速ですが、問題はロックにあります。
この問題は解決しましたか？
Pop os 19.10、pipenv、aptのバージョン11.9.0、python3.7.5を使用しています。

同じトピックhttps://github.com/pypa/pipenv/issues/1914#issuecomment-457965038に関する＃1914からのこの優れたコメントに注目したいと思い

このアプローチの実現可能性について、開発者がコメントできるかどうか疑問に思います。

実際には、環境を削除して最初から再作成し、ロックファイルを更新する方が速いことに気づきました。
これは、 pipenv lockとpipenv install some-package両方を実行する場合に当てはまります。

私はpipenvが本当に好きですが、帯域幅と時間はそれほど好きではありません。 だから私は次を使用して問題を解決することになります：

$ pipenv --rm
$ virtualenv .
$ source bin/activate
$ # Create a requirement file (Cause pipenv lock -r > requirements.txt... you know!)
$ pip install -r requirement.txt

開発者の幸運を祈ります...

@ravexina提案をありがとう、私は確かにしようとします