Pipenv: 依存関係を解決できませんでした。 回帰？

pipenvは、現在のラウンド候補に厳密なピンを追加しているようです。

これは、次のラウンドで、別のパッケージが現在の候補と一致しないバージョンを必要とする場合、別の候補を見つけようとする代わりに（このように）失敗することを意味します。 これが解決アルゴリズムの仕組みです。安定するまで、新しい制約を使用して完全に再計算します。

何が原因なのかわかりません。
以前にpip-tools単独で使用した場合、これを再現するには、キャッシュ（ --clear ）をクリアする必要があることに気付きました。
私はこれではない伝えることができますpip-toolsバグ、およびその直接のパッチに関連していないpip-tools （私は試すためにそれらすべてを除去し、これが引き続き発生します）。
これがお役に立てば幸いです。

了解しました。犯人を見つけました。
https://github.com/kennethreitz/pipenv/blob/master/pipenv/patched/pip/req/req_set.py#L752

self.requirements.values()には、固定されたreq_to_install自体が含まれていますが、これは依存関係として返されるのは誤りであり、後続のパッケージに適合しないバージョンが必要な場合、ここのように依存関係の解決が失敗する可能性があります。現在の候補者。 これを行うことは、私たちの最初の候補者が正しい候補者でなければならない、または失敗することを前提としています。

@kennethreitz私が理解していることから、それは「深い余分な解決」を行うことでした。 それが正確に何を意味するのか理解できません。 私はこれを刺し続ける準備ができていますが、間違った方向に進まないようにするためにいくつかの情報が必要です。

私は同じ問題を見ていると思います：

$ pipenv --version
pipenv, version 8.2.7

$ pipenv install
Pipfile.lock not found, creating…
Locking [dev-packages] dependencies…
Locking [packages] dependencies…
Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
  You can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
Could not find a version that matches django==2.0a1,>=1.8,>=1.8.0
Tried: 1.1.3, 1.1.4, 1.2, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.2.6, 1.2.7, 1.3, 1.3.1, 1.3.2, 1.3.3, 1.3.4, 1.3.5, 1.3.6, 1.3.7, 1.4, 1.4.1, 1.4.2, 1.4.3, 1.4.4, 1.4.5, 1.4.6, 1.4.7, 1.4.8, 1.4.9, 1.4.10, 1.4.11, 1.4.12, 1.4.13, 1.4.14, 1.4.15, 1.4.16, 1.4.17, 1.4.18, 1.4.19, 1.4.20, 1.4.21, 1.4.22, 1.5, 1.5.1, 1.5.2, 1.5.2, 1.5.3, 1.5.4, 1.5.5, 1.5.6, 1.5.7, 1.5.8, 1.5.8, 1.5.9, 1.5.10, 1.5.11, 1.5.12, 1.5.12, 1.6, 1.6, 1.6.1, 1.6.1, 1.6.2, 1.6.2, 1.6.3, 1.6.3, 1.6.4, 1.6.4, 1.6.5, 1.6.5, 1.6.6, 1.6.6, 1.6.7, 1.6.7, 1.6.8, 1.6.8, 1.6.9, 1.6.9, 1.6.10, 1.6.10, 1.6.11, 1.6.11, 1.7, 1.7, 1.7.1, 1.7.1, 1.7.2, 1.7.2, 1.7.3, 1.7.3, 1.7.4, 1.7.4, 1.7.5, 1.7.5, 1.7.6, 1.7.6, 1.7.7, 1.7.7, 1.7.8, 1.7.8, 1.7.9, 1.7.9, 1.7.10, 1.7.10, 1.7.11, 1.7.11, 1.8a1, 1.8b1, 1.8b2, 1.8rc1, 1.8, 1.8, 1.8.1, 1.8.1, 1.8.2, 1.8.2, 1.8.3, 1.8.3, 1.8.4, 1.8.4, 1.8.5, 1.8.5, 1.8.6, 1.8.6, 1.8.7, 1.8.7, 1.8.8, 1.8.8, 1.8.9, 1.8.9, 1.8.10, 1.8.10, 1.8.11, 1.8.11, 1.8.12, 1.8.12, 1.8.13, 1.8.13, 1.8.14, 1.8.14, 1.8.15, 1.8.15, 1.8.16, 1.8.16, 1.8.17, 1.8.17, 1.8.18, 1.8.18, 1.9a1, 1.9b1, 1.9rc1, 1.9rc2, 1.9, 1.9, 1.9.1, 1.9.1, 1.9.2, 1.9.2, 1.9.3, 1.9.3, 1.9.4, 1.9.4, 1.9.5, 1.9.5, 1.9.6, 1.9.6, 1.9.7, 1.9.7, 1.9.8, 1.9.8, 1.9.9, 1.9.9, 1.9.10, 1.9.10, 1.9.11, 1.9.11, 1.9.12, 1.9.12, 1.9.13, 1.9.13, 1.10a1, 1.10a1, 1.10b1, 1.10b1, 1.10rc1, 1.10rc1, 1.10, 1.10, 1.10.1, 1.10.1, 1.10.2, 1.10.2, 1.10.3, 1.10.3, 1.10.4, 1.10.4, 1.10.5, 1.10.5, 1.10.6, 1.10.6, 1.10.7, 1.10.7, 1.10.8, 1.10.8, 1.11a1, 1.11b1, 1.11rc1, 1.11rc1, 1.11, 1.11, 1.11.1, 1.11.1, 1.11.2, 1.11.2, 1.11.3, 1.11.3, 1.11.4, 1.11.4, 1.11.5, 1.11.5, 1.11.6, 1.11.6, 2.0a1

ここで、 2.0a1は明らかに利用可能なオプションの1つです。

https://github.com/kennethreitz/pipenv/issues/786が原因で、古いバージョンのpipenvで依存関係の解決をテストできません

同じ問題-特にリクエストについて不平を言っています。

これは、 @ vphilipponのコメントに関連していると私が信じているバグです。 ただし、＃909とは関係ないと思います。

正確、＃909とは関係ありません。
私が言ったように、ここで「ディープエクストラの解決」が正確に何を意味するのかを理解するには、 @ maintainersの1人からの入力が必要です。 修正はありますが、最初に何も壊さないようにもっと知りたいです。

または、先に進んで修正を加えたPRを開き、そこで話し合うこともできます。 私は私の自由な時間で見るでしょう。

@vphilipponこれは組織内ではなく、ケネスの個人的なリポジトリであるため、残念ながら、私たち全員を取得するための便利な@タグはありません。 @erinxoconと私にpingを

ここでピップするパッチは、残念ながらケネスの頭のどこかに閉じ込められています。 ここで何が起こっているのか理解していないか、見る時間がなかったと思います。 何が起こっていると思うかをまとめる時間があれば、私は仮定を検証するのを手伝うことができます。 それまでは、これは変更を加える前に軽く踏み回さなければならないことです。

@nateprewittわかりました、できるだけ多く追加します。 椅子をつかみます。

どうしましたか？

https://github.com/kennethreitz/pipenv/issues/875#issuecomment -335570812で、エラーの原因を指摘しました。解決ラウンドで選択された候補は、候補自体の固定された依存関係として直接追加されますが、これは間違っています（今後の詳細）

https://github.com/kennethreitz/pipenv/issues/875#issuecomment -336609268で、そのピンのソースを見つけました。戻り値に追加されたself.requirements.values()には、現在のパッケージへのピンが含まれています。 。 言い換えると、 _prepare_fileはパッケージの依存関係（または「インストールする追加のInstallRequirementsのリスト」）を返す必要がありますが、現在は、独自の依存関係として固定された自身が含まれています。

パッケージ自体を、それ自体の依存関係として固定することが本当に間違っている理由を示すために、依存関係解決アルゴリズムがどのように機能するかを簡単に説明します。

1. initial_constraints_set 、 InstallRequirementsリストを取得します（例： requests>=2.18 ）。
2. additional_constraintsとcandidateを空のセットとして定義します。
3. initial_constraints_setとadditional_constraintsの和集合を尊重するcandidateセット（例： requests==2.18.4 ）を選択します
4. 候補ごとに、すべての候補の依存関係のセットをadditional_constraintsとして取得して結合します（例： certifi>=2017.4.17 ）。
5. additional_constraintsが変更された場合は、 candidateをクリアして、3に戻ります。
6. 完了した候補のセットを返します。

それでは、上記を念頭に置いて問題を再現しましょう。

この問題を再現するには、次のPipfileが必要です（Django1.11をサポートする `django-cms 3.4.5がリリースされたため）：

[[source]]
url = "https://pypi.python.org/simple"
verify_ssl = true

[packages]
django-cms = "==3.4.4"
django = "*"

そして今pipenv lock --verbose --clear ：

Courtesy Notice: Pipenv found itself running within a virtual environment, so it will automatically use that environment, instead of creating its own for any project.
Locking [dev-packages] dependencies…
Using pip: -i https://pypi.python.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.python.org/simple

                          ROUND 1
Current constraints:
  django
  django-cms==3.4.4

Finding the best candidates:
  found candidate django==1.11.6 (constraint was <any>)
  found candidate django-cms==3.4.4 (constraint was ==3.4.4)

Finding secondary dependencies:
  django-cms==3.4.4 not in cache, need to check index
  django-cms==3.4.4         requires django-classy-tags>=0.7.2, django-cms==3.4.4, django-formtools>=1.0, django-sekizai>=0.7, django-treebeard>=4.0.1, Django<1.11,>=1.8, djangocms-admin-style>=1.0
  django==1.11.6 not in cache, need to check index
  django==1.11.6            requires django==1.11.6, pytz

New dependencies found in this round:
  adding [u'django', '<1.11,==1.11.6,>=1.8', '[]']
  adding [u'django-classy-tags', '>=0.7.2', '[]']
  adding [u'django-cms', '==3.4.4', '[]']
  adding [u'django-formtools', '>=1.0', '[]']
  adding [u'django-sekizai', '>=0.7', '[]']
  adding [u'django-treebeard', '>=4.0.1', '[]']
  adding [u'djangocms-admin-style', '>=1.0', '[]']
  adding [u'pytz', '', '[]']
Removed dependencies in this round:
Unsafe dependencies in this round:
------------------------------------------------------------
Result of round 1: not stable

                          ROUND 2
Current constraints:
  django<1.11,==1.11.6,>=1.8
  django-classy-tags>=0.7.2
  django-cms==3.4.4
  django-formtools>=1.0
  django-sekizai>=0.7
  django-treebeard>=4.0.1
  djangocms-admin-style>=1.0
  pytz

Finding the best candidates:
Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
  You can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
Could not find a version that matches django<1.11,==1.11.6,>=1.8
Tried: 1.1.3, 1.1.4, 1.2, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, 1.2.6, 1.2.7, 1.3, 1.3.1, 1.3.2, 1.3.3, 1.3.4, 1.3.5, 1.3.6, 1.3.7, 1.4, 1.4.1, 1.4.2, 1.4.3, 1.4.4, 1.4.5, 1.4.6, 1.4.7, 1.4.8, 1.4.9, 1.4.10, 1.4.11, 1.4.12, 1.4.13, 1.4.14, 1.4.15, 1.4.16, 1.4.17, 1.4.18, 1.4.19, 1.4.20, 1.4.21, 1.4.22, 1.5, 1.5.1, 1.5.2, 1.5.2, 1.5.3, 1.5.4, 1.5.5, 1.5.6, 1.5.7, 1.5.8, 1.5.8, 1.5.9, 1.5.10, 1.5.11, 1.5.12, 1.5.12, 1.6, 1.6, 1.6.1, 1.6.1, 1.6.2, 1.6.2, 1.6.3, 1.6.3, 1.6.4, 1.6.4, 1.6.5, 1.6.5, 1.6.6, 1.6.6, 1.6.7, 1.6.7, 1.6.8, 1.6.8, 1.6.9, 1.6.9, 1.6.10, 1.6.10, 1.6.11, 1.6.11, 1.7, 1.7, 1.7.1, 1.7.1, 1.7.2, 1.7.2, 1.7.3, 1.7.3, 1.7.4, 1.7.4, 1.7.5, 1.7.5, 1.7.6, 1.7.6, 1.7.7, 1.7.7, 1.7.8, 1.7.8, 1.7.9, 1.7.9, 1.7.10, 1.7.10, 1.7.11, 1.7.11, 1.8a1, 1.8b1, 1.8b2, 1.8rc1, 1.8, 1.8, 1.8.1, 1.8.1, 1.8.2, 1.8.2, 1.8.3, 1.8.3, 1.8.4, 1.8.4, 1.8.5, 1.8.5, 1.8.6, 1.8.6, 1.8.7, 1.8.7, 1.8.8, 1.8.8, 1.8.9, 1.8.9, 1.8.10, 1.8.10, 1.8.11, 1.8.11, 1.8.12, 1.8.12, 1.8.13, 1.8.13, 1.8.14, 1.8.14, 1.8.15, 1.8.15, 1.8.16, 1.8.16, 1.8.17, 1.8.17, 1.8.18, 1.8.18, 1.9a1, 1.9b1, 1.9rc1, 1.9rc2, 1.9, 1.9, 1.9.1, 1.9.1, 1.9.2, 1.9.2, 1.9.3, 1.9.3, 1.9.4, 1.9.4, 1.9.5, 1.9.5, 1.9.6, 1.9.6, 1.9.7, 1.9.7, 1.9.8, 1.9.8, 1.9.9, 1.9.9, 1.9.10, 1.9.10, 1.9.11, 1.9.11, 1.9.12, 1.9.12, 1.9.13, 1.9.13, 1.10a1, 1.10a1, 1.10b1, 1.10b1, 1.10rc1, 1.10rc1, 1.10, 1.10, 1.10.1, 1.10.1, 1.10.2, 1.10.2, 1.10.3, 1.10.3, 1.10.4, 1.10.4, 1.10.5, 1.10.5, 1.10.6, 1.10.6, 1.10.7, 1.10.7, 1.10.8, 1.10.8, 1.11a1, 1.11b1, 1.11rc1, 1.11rc1, 1.11, 1.11, 1.11.1, 1.11.1, 1.11.2, 1.11.2, 1.11.3, 1.11.3, 1.11.4, 1.11.4, 1.11.5, 1.11.5, 1.11.6, 1.11.6

• 1回の解決ラウンドで、 django==*とdjango-cms==3.4.4をインストールする必要があることが検出されました。
• 候補を選択します： django==1.11.6 、 django-cms==3.4.4 。
• 依存関係を取得します（重要な部分に焦点を当てます）：
  
  
  
  • django-cms==3.4.4はdjango<1.11,>=1.8が必要です
  
  
  • djangoはdjango==1.11.6が必要です（これは正しくありません。djangoはそれ自体を必要としません！パッケージはそれ自体を必要としません！）
  
  
• 依存関係指定子をマージします。
  
  
  
  • django <1.11,==1.11.6,>=1.8が必要になりました（これがどこに向かっているのかがわかります...）
  
  
• 制約が変更され、候補の選択に戻りました。
• <1.11,==1.11.6,>=1.8であるdjango候補を見つけてみてください：
  
  
  
  • Could not find a version that matches django<1.11,==1.11.6,>=1.8 [...]
  
  

何が起こったのか（ pip-tools場合と同様に、パッチが適用されていないpipで、-rebuildを使用してキャッシュをクリアします）：

• 1回の解決ラウンドで、 django==*とdjango-cms==3.4.4をインストールする必要があることが検出されました。
• 候補を選択します： django==1.11.6 、 django-cms==3.4.4 。
• 依存関係を取得します（重要な部分に焦点を当てます）：
  
  
  
  • django-cms==3.4.4はdjango<1.11,>=1.8が必要です
  
  
  • djangoはpytz djangoが必要ですが、 django==1.11.6は必要あり
  
  
• 依存関係指定子をマージします。
  
  
  
  • django <1.11,>=1.8が必要になりました（はるかに良い...）
  
  
• 制約が変更され、候補の選択に戻りました。
• <1.11,>=1.8であるdjango候補を見つけてみてください：
  
  
  
  • 新しいdjango候補、おそらくdjango==1.10.8
  
  
• 依存関係を計算し、続行し、問題なく解決します。

ここから何をしますか？

まあ、削除するself.requirements.values()におけるリターンから_prepare_file修正この問題は、私はそれを確認することができます。 残念ながら、なぜそこに追加されたのか正確にはわかりません。

たぶん、ケネスは、「ディープエクストラの解決」に関連する情報を取得するために、候補自体に対して何らかの操作を実行した後、候補自体のInstallRequirementオブジェクトを返したいと考えていました（私はここで実際にストレッチを行っています）。 追加のInstallRequirementオブジェクトを戻り値に保持するようにパッチにパッチを適用することもできますが、最初に固定を解除します。 それは意図的なものではなく、たとえそうであったとしても、壊れているしています。

それだけだと思います。 ☕️

@vphilippon 、このような詳細な内訳を入れてくれてありがとう！ これは間違いなく私にとって物事をクリアします。

コミットログを掘り下げてみると、これはae4591b2に追加されました。あなたが言ったように、これが追加された理由はかなり不明です。 次のステップは、このために失敗したテストケースと、「深い依存関係」をインストールするための実用的なテストケースをまとめることだと思います。 この問題を引き起こすチケットはなく、コミットメッセージは役に立たないので、現時点では推測しているだけです。

コードを見ると、これはrequests[security]ような宣言があり、依存関係がcertifi[some-extra]である可能性があり、これも解決する必要があることを解決しようとしていると思います。 少なくとも私が考えることができるのはそれだけです。 Djangoの世界には、これを行っている何かがあると思います。テストを作成できる例を見つけることができれば。

そう！ 誰かがこれらのテストをまとめて、最初のテストが失敗し、「深い依存関係」が機能することを確認したい場合は、 self.requirements.values()宣言を削除することを検討できます。

@nateprewittこれがあなたの意味を説明していると私が思うものです：
https://github.com/vphilippon/testdeepextra

ただし、「foo [a]はbar [b]に依存します」という深い解像度は、そのリポジトリでテストできるため、 pip-toolsではすでに問題ないようです。
そのため、元々 pip-tools機能していなかったものに対してパッチを想定しているため、そのパッチは正確にはそうではない可能性があります。 特定の場合を除いて、ここでテストすることはできませんでした。

とにかく、そのパッチを使用した場合と使用しない場合で、そのレポ（すぐに実行する時間はありません）を使用して、エクストラのpipenvの解決動作をテストし、効果があるかどうかを確認できます。 /またはpip-toolsの出力と比較します。 少なくとも出発点があります。

Warning: Your dependencies could not be resolved. You likely have a mismatch in your sub-dependencies.
  You can use $ pipenv install --skip-lock to bypass this mechanism, then run $ pipenv graph to inspect the situation.
Could not find a version that matches sanic-plugins-framework==0.5.0.dev20171225,>=0.5.0.dev20171225
Tried: 0.2.0.dev20171102, 0.2.0.dev20171102, 0.3.0.dev20171102, 0.3.0.dev20171102, 0.3.1.dev20171102, 0.3.1.dev20171102, 0.3.2.dev20171102, 0.3.2.dev20171102, 0.3.3.dev20171102, 0.3.3.dev20171102, 0.4.0.dev20171103, 0.4.0.dev20171103, 0.4.1.dev20171103, 0.4.1.dev20171103, 0.4.2.dev20171106, 0.4.2.dev20171106, 0.4.4.dev20171107, 0.4.4.dev20171107, 0.4.5.dev20171113, 0.4.5.dev20171113, 0.5.0.dev20171225, 0.5.0.dev20171225, 0.5.2.dev20180201, 0.5.2.dev20180201

1. パッケージのバージョンが「*」に等しい場合にこのエラーが発生しましたが、「== 0.1.2」などの既知のバージョンに変更すると、正常に機能します。
2. 残念ながら、 pipenv install sanic-plugins-framework==0.5.0.dev20171225 、この大きなエラーメッセージが返されました。 上記のすべてのバージョンが「0.5.0.dev20171225」より大きくない可能性があります
3. これをカバーするにはどうすればよいですか

pipenv lock —pre —clear

@Jasonseyにあなたのビットを共有してくれて、 ありがとう。
特にsanic-plugins-frameworkで問題が発生し、 --pre （_ Pre-releases._フラグを許可）を追加すると、パッケージのインストールに役立ちました🙌

これは修正されたことがありますか？ 私はまだ同じ誤った動作をしています。
https://github.com/pypa/pipfile/issues/114