Pipenv: Abhängigkeiten konnten nicht aufgelöst werden. Regression?

Es sieht so aus, als ob pipenv den aktuellen Rundenkandidaten einen strengen Pin hinzufügt.

Dies bedeutet, dass wenn in einer nächsten Runde für ein anderes Paket eine Version erforderlich ist, die nicht mit dem aktuellen Kandidaten übereinstimmt, dies fehlschlägt (wie folgt), anstatt zu versuchen, einen anderen Kandidaten zu finden. So funktioniert der Auflösungsalgorithmus: Berechnen Sie die neuen Einschränkungen vollständig neu, bis sie sich stabilisiert haben.

Ich bin mir nicht sicher, was das verursacht.
Ich habe festgestellt, dass ich zum Reproduzieren den Cache leeren muss ( --clear ), wenn ich zuvor allein pip-tools .
Ich kann sagen, dass dies kein pip-tools Fehler ist und nicht direkt mit den Patches von pip-tools (ich habe sie alle entfernt, um es zu versuchen, und dies tritt immer noch auf).
Ich hoffe das hilft.

Okay, fand den Täter:
https://github.com/kennethreitz/pipenv/blob/master/pipenv/patched/pip/req/req_set.py#L752

self.requirements.values() enthält das req_to_install selbst, das falsch ist, um als Abhängigkeit zurückgegeben zu werden, und kann dazu führen, dass die Abhängigkeitsauflösung fehlschlägt, wie hier, wenn für ein nachfolgendes Paket eine Version erforderlich ist, die nicht zum passt aktueller Kandidat. Dies setzt voraus, dass unser erster Kandidat der richtige sein muss oder scheitert.

@kennethreitz Soweit ich weiß, war das "Deep Extras Resolving". Ich bin mir nicht sicher, ob ich verstehe, was das genau bedeuten soll. Ich bin bereit, weiter darauf zu stechen, aber ich brauche einige Informationen, um nicht in die falsche Richtung zu gehen.

Ich glaube, ich sehe das gleiche Problem:

$ 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

Dabei ist 2.0a1 eindeutig eine der verfügbaren Optionen.

Ich kann die Abhängigkeitsauflösung in älteren Versionen von pipenv aufgrund von https://github.com/kennethreitz/pipenv/issues/786 nicht testen

Gleiches Problem - es beschwert sich speziell über Anfragen.

Dies ist ein Fehler, von dem ich glaube, dass er mit @vphilippons Kommentar zusammenhängt. Ich glaube jedoch nicht, dass es mit # 909 zusammenhängt.

Genau, nicht verwandt mit # 909.
Wie gesagt, ich brauche die Eingabe von einem der @Maintainer, um zu verstehen, was "Deep Extras Resolving" genau hier bedeutet. Ich habe eine Lösung, aber ich würde gerne mehr wissen, um nicht zuerst etwas zu beschädigen.

Oder ich könnte eine PR mit dem Fix eröffnen und dort diskutieren. Ich werde mit meiner Freizeit sehen.

@vphilippon Da dies keine Organisation ist, sondern ein persönliches Repo für Kenneth, haben wir leider kein handliches @ -Tag, um uns alle zu erreichen. Ich würde vorschlagen, nur @erinxocon und mich

Der Patch, der hier zu pipen ist, ist leider irgendwo in Kenneths Kopf weggesperrt. Ich glaube nicht, dass ich verstehe oder Zeit hatte, mir anzusehen, was hier los ist. Wenn Sie etwas Zeit finden, um zu kompilieren, was Ihrer Meinung nach vor sich geht, kann ich versuchen, Annahmen zu überprüfen. Bis dahin müssen wir jedoch leicht herumlaufen, bevor wir Änderungen vornehmen.

@nateprewitt Okay , ich werde so viel wie möglich hinzufügen. Nimm dir einen Stuhl.

Was ist los?

In https://github.com/kennethreitz/pipenv/issues/875#issuecomment -335570812 habe ich die Fehlerquelle notiert: Ausgewählte Kandidaten in einer Auflösungsrunde werden als angeheftete Abhängigkeit des Kandidaten selbst direkt hinzugefügt, was falsch ist ( mehr dazu in Kürze)

In https://github.com/kennethreitz/pipenv/issues/875#issuecomment -336609268 habe ich die Quelle dieses Pins gefunden: Das self.requirements.values() das zum Rückgabewert hinzugefügt wurde, enthält einen Pin zum aktuellen Paket . Mit anderen Worten, _prepare_file sollte die Abhängigkeiten eines Pakets zurückgeben (oder "Eine Liste zusätzlicher Installationsanforderungen, die ebenfalls installiert werden sollen"), aber jetzt enthält es sich selbst als eigene Abhängigkeit.

Um zu demonstrieren, warum es wirklich falsch ist, das Paket selbst als eigene Abhängigkeit zu fixieren, funktioniert der Algorithmus zum Auflösen von Abhängigkeiten wie folgt:

1. Holen Sie sich die initial_constraints_set , eine Liste von InstallRequirements (Beispiel: requests>=2.18 ).
2. Definieren Sie additional_constraints und candidate als leere Menge.
3. Wählen Sie einen Satz von candidate (z. B. requests==2.18.4 ), der die Vereinigung von initial_constraints_set und additional_constraints
4. Ermitteln und kombinieren Sie für jeden Kandidaten die Abhängigkeiten aller Kandidaten als additional_constraints (Beispiel: certifi>=2017.4.17 ).
5. Wenn sich additional_constraints geändert hat, löschen Sie candidate und kehren Sie zu 3 zurück.
6. Geben Sie den Kandidatensatz zurück, fertig.

Lassen Sie uns nun das Problem unter Berücksichtigung der oben genannten Punkte reproduzieren.

Um das Problem zu reproduzieren, benötigen Sie dieses Pipfile (da `django-cms 3.4.5 mit Django 1.11-Unterstützung veröffentlicht wurde):

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

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

Und jetzt 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

• In einer einzigen Auflösungsrunde stellen wir fest, dass wir django==* und django-cms==3.4.4 installieren müssen.
• Wir wählen Kandidaten aus: django==1.11.6 , django-cms==3.4.4 .
• Wir bekommen die Abhängigkeiten (ich werde mich auf den wichtigen Teil konzentrieren):
  
  
  
  • django-cms==3.4.4 erfordert django<1.11,>=1.8
  
  
  • django erfordert django==1.11.6 (Dies ist nicht wahr, Django benötigt sich nicht selbst! Kein Paket erfordert sich selbst!)
  
  
• Wir führen den Abhängigkeitsspezifizierer zusammen:
  
  
  
  • Wir benötigen jetzt django <1.11,==1.11.6,>=1.8 (Sie können sehen, wohin das führt ...)
  
  
• Die Einschränkungen haben sich geändert, zurück zur Auswahl des Kandidaten.
• Versuchen Sie, einen Kandidaten für django , der <1.11,==1.11.6,>=1.8 :
  
  
  
  • Could not find a version that matches django<1.11,==1.11.6,>=1.8 [...]
  
  

Was hätte passieren sollen (wie in pip-tools , mit einem nicht gepatchten pip , mit --rebuild, um den Cache zu leeren):

• In einer einzigen Auflösungsrunde stellen wir fest, dass wir django==* und django-cms==3.4.4 installieren müssen.
• Wir wählen Kandidaten aus: django==1.11.6 , django-cms==3.4.4 .
• Wir bekommen die Abhängigkeiten (ich werde mich auf den wichtigen Teil konzentrieren):
  
  
  
  • django-cms==3.4.4 erfordert django<1.11,>=1.8
  
  
  • django erfordert pytz , aber nicht django==1.11.6
  
  
• Wir führen den Abhängigkeitsspezifizierer zusammen:
  
  
  
  • Wir benötigen jetzt django <1.11,>=1.8 (viel besser ...)
  
  
• Die Einschränkungen haben sich geändert, zurück zur Auswahl des Kandidaten.
• Versuchen Sie, einen Kandidaten für django , der <1.11,>=1.8 :
  
  
  
  • Wählt einen neuen django Kandidaten aus, wahrscheinlich django==1.10.8
  
  
• Berechnet Abhängigkeiten, macht weiter und löst sich glücklich auf.

Was ist von hier aus zu tun?

Das Entfernen des self.requirements.values() aus der Rückgabe in _prepare_file behebt dieses Problem. Ich kann es bestätigen. Leider habe ich nicht genau herausgefunden

Vielleicht wollte Kenneth ein InstallRequirement -Objekt für den Kandidaten selbst zurückgeben, nachdem er eine Operation daran durchgeführt hatte, um Informationen zu erhalten, die sich auf das "Auflösen tiefer Extras" beziehen (ich bin hier wirklich auf einer Strecke). Ich könnte versuchen, den Patch zu patchen, um das zusätzliche InstallRequirement -Objekt im zurückgegebenen Wert zu belassen, aber zuerst entfernen. Ich bin mir ziemlich sicher, dass das nicht beabsichtigt war, und selbst wenn es so war, ist es kaputt.

Ich denke das ist es. ☕️

@vphilippon , vielen Dank für die detaillierte Aufschlüsselung! Das klärt definitiv die Dinge für mich auf.

Beim Zurückblättern durch das Festschreibungsprotokoll wurde dies in ae4591b2 hinzugefügt, und wie Sie gesagt haben, ist es ziemlich unklar, warum dies hinzugefügt wurde. Ich denke, der nächste Schritt besteht darin, einen fehlgeschlagenen Testfall dafür und einen funktionierenden Testfall für die Installation von "tiefen Abhängigkeiten" zusammenzustellen. Es gibt keine Tickets, die dieses Problem ansprechen, und die Commit-Nachrichten sind nicht hilfreich, sodass wir an dieser Stelle nur raten.

Wenn ich mir den Code anschaue, dass dies versucht, eine Deklaration wie requests[security] zu lösen, die möglicherweise eine Abhängigkeit certifi[some-extra] die ebenfalls gelöst werden muss. Das ist das einzige, woran ich zumindest denken kann. Ich wette, es gibt etwas im Django-Universum, das dies tut, und wenn wir ein Beispiel finden, mit dem wir einen Test schreiben können.

Damit! Wenn jemand daran arbeiten möchte, diese Tests zusammenzustellen, um sicherzustellen, dass der erste fehlschlägt und die "tiefe Abhängigkeit" funktioniert, können wir die self.requirements.values() -Deklaration entfernen.

@nateprewitt Hier ist etwas, von dem ich denke, dass es beschreibt, was du
https://github.com/vphilippon/testdeepextra

Die tiefe Auflösung "foo [a] hängt von bar [b] ab" scheint jedoch in pip-tools bereits in Ordnung zu sein, da sie mit diesem Repo getestet werden kann.
Dieser Patch ist möglicherweise nicht genau das, da ich davon ausgehen würde, dass er für etwas verwendet wird, das ursprünglich nicht in pip-tools funktioniert hat. Es sei denn, es ist für einen bestimmten Fall, ich konnte hier nicht testen.

Wie auch immer, wir können immer noch das Auflösungsverhalten des Extra von pipenv mit diesem Repo (für das ich nicht sofort Zeit habe) mit und ohne diesen Patch testen und sehen, ob es irgendwelche Auswirkungen hat, und / oder vergleiche mit der Ausgabe von pip-tools . Zumindest haben wir einen Ausgangspunkt.

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. Ich habe diesen Fehler erhalten, wenn die Version der Pakete gleich '*' ， ist, aber wenn ich sie auf die bekannte Version ändere, wie z. B. '== 0.1.2', funktioniert sie gut.
2. Leider habe ich pipenv install sanic-plugins-framework==0.5.0.dev20171225 diese große Fehlermeldung erhalten. Möglicherweise ist die gesamte obige Version nicht größer als '0.5.0.dev20171225'.
3. Wie soll ich das abdecken?

pipenv lock —pre —clear

Vielen Dank an @Jasonsey für das Teilen Ihres Beitrags und an
Ich hatte ein spezielles Problem mit sanic-plugins-framework , und das Hinzufügen des --pre (_Allow pre-release._ flag) half mir bei der Installation des Pakets 🙌

Wurde das jemals behoben? Ich bekomme immer noch das gleiche fehlerhafte Verhalten.
https://github.com/pypa/pipfile/issues/114