Pipenv: Les dépendances n'ont pas pu être résolues. Régression?

Il semble que pipenv ajoute une épingle stricte aux candidats du tour en cours.

Cela signifie que si au prochain tour, un autre paquet nécessite une version ne correspondant pas au candidat actuel, il échouera (comme ceci) au lieu d'essayer de trouver un autre candidat. C'est ainsi que fonctionne l'algorithme de résolution: recalculez complètement avec les nouvelles contraintes jusqu'à ce qu'il se stabilise.

Je ne suis pas sûr de ce qui cause cela.
J'ai remarqué que pour reproduire cela, je dois vider le cache ( --clear ) si j'ai utilisé pip-tools seul avant.
Je peux dire que ce n'est pas un bogue pip-tools , et que ce n'est pas directement lié aux correctifs de pip-tools (je les ai tous supprimés pour essayer, et cela se produit toujours).
J'espère que cela aide.

Très bien, a trouvé le coupable:
https://github.com/kennethreitz/pipenv/blob/master/pipenv/patched/pip/req/req_set.py#L752

self.requirements.values() contient le req_to_install lui-même, épinglé, qui n'est pas retourné en tant que dépendance, et peut faire échouer la résolution de la dépendance, comme ici, si un paquet ultérieur nécessite une version qui ne correspond pas au candidat actuel. Cela suppose que notre premier candidat doit être le bon, ou échouer.

@kennethreitz D'après ce que je comprends, c'était de faire des "résolutions de suppléments profonds". Je ne suis pas sûr de comprendre ce que cela signifie exactement. Je suis prêt à continuer à poignarder cela, mais j'aurais besoin d'informations pour ne pas aller dans la mauvaise direction.

Je pense que je vois le même problème:

$ 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

où 2.0a1 est clairement l'une des options disponibles.

Je ne peux pas tester la résolution des dépendances dans les anciennes versions de pipenv en raison de https://github.com/kennethreitz/pipenv/issues/786. À mon avis, les corrections de bogues critiques devraient être appliquées à au moins quelques-unes des versions majeures les plus récentes.

Même problème - il se plaint spécifiquement des demandes.

C'est un bug que je crois lié au commentaire de

Exacts, sans rapport avec # 909.
Comme je l'ai dit, j'aurai besoin de la contribution de l'un des @maintainers pour comprendre ce que signifie exactement "résolution des extras profonds". J'ai un correctif, mais j'aimerais en savoir plus pour ne rien casser au préalable.

Ou je pourrais aller de l'avant et ouvrir un PR avec le correctif et en discuter. Je verrai avec mon temps libre.

@vphilippon Comme il ne s'agit pas d'une organisation mais plutôt d'un dépôt personnel pour Kenneth, nous n'avons malheureusement pas de balise @ pratique pour nous tous. Je suggérerais simplement de cingler @erinxocon et moi-même.

Le patch à pip ici est malheureusement enfermé quelque part dans la tête de Kenneth. Je ne pense pas avoir compris, ni avoir eu le temps de regarder, ce qui se passe ici. Si vous trouvez le temps de compiler ce que vous pensez être en train de se passer, je peux essayer de vous aider à vérifier les hypothèses. Jusque-là cependant, c'est quelque chose que nous devrons marcher légèrement avant d'apporter des modifications.

@nateprewitt Très bien , j'ajouterai tout ce que je peux. Prendre une chaise.

Qu'est-ce qui ne va pas?

Dans https://github.com/kennethreitz/pipenv/issues/875#issuecomment -335570812, j'ai noté la source de l'erreur: les candidats sélectionnés dans un tour de résolution sont ajoutés directement en tant que dépendance épinglée du candidat lui-même, ce qui est faux ( plus à ce sujet à venir)

Dans https://github.com/kennethreitz/pipenv/issues/875#issuecomment -336609268, j'ai trouvé la source de cette épingle: le self.requirements.values() qui a été ajouté à la valeur de retour inclut une épingle au package actuel . En d'autres termes, _prepare_file devrait renvoyer les dépendances d'un paquet (ou "Une liste des InstallRequirements supplémentaires à installer également"), mais maintenant il s'inclut lui-même, épinglé, comme sa propre dépendance.

Pour aider à démontrer pourquoi le fait d'avoir le package lui-même, épinglé, comme sa propre dépendance, est vraiment faux, voici comment fonctionne l'algorithme de résolution de dépendances, en bref:

1. Obtenez le initial_constraints_set , une liste de InstallRequirements (ex: requests>=2.18 ).
2. Définissez additional_constraints et candidate comme un ensemble vide.
3. Sélectionnez un ensemble de candidate (ex: requests==2.18.4 ) qui respectent l'union de initial_constraints_set et additional_constraints
4. Pour chaque candidat, récupérez et combinez l'ensemble des dépendances de tous les candidats, comme additional_constraints (ex: certifi>=2017.4.17 )
5. Si additional_constraints a changé, effacez candidate et revenez à 3.
6. Retournez l'ensemble des candidats, c'est fait.

Maintenant, reproduisons le problème avec ce qui précède à l'esprit.

Pour reproduire le problème, vous avez besoin de ceci Pipfile (car `django-cms 3.4.5 avec le support Django 1.11 est sorti):

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

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

Et maintenant 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

• En un seul tour de résolution, nous détectons que nous devons installer django==* et django-cms==3.4.4 .
• Nous sélectionnons le candidat: django==1.11.6 , django-cms==3.4.4 .
• Nous obtenons les dépendances (je vais me concentrer sur la partie importante):
  
  
  
  • django-cms==3.4.4 nécessite django<1.11,>=1.8
  
  
  • django requiert django==1.11.6 (Ce n'est pas vrai, django n'a pas besoin de lui-même! Aucun paquet ne l'exige!)
  
  
• Nous fusionnons le spécificateur de dépendances ensemble:
  
  
  
  • Nous avons maintenant besoin de django <1.11,==1.11.6,>=1.8 (vous pouvez voir où cela va ...)
  
  
• Les contraintes ont changé, retour à la sélection du candidat.
• Essayez de trouver un candidat pour django soit <1.11,==1.11.6,>=1.8 :
  
  
  
  • Could not find a version that matches django<1.11,==1.11.6,>=1.8 [...]
  
  

Ce qui aurait dû se passer (comme dans pip-tools , avec un pip corrigé, avec --rebuild pour vider le cache):

• En un seul tour de résolution, nous détectons que nous devons installer django==* et django-cms==3.4.4 .
• Nous sélectionnons le candidat: django==1.11.6 , django-cms==3.4.4 .
• Nous obtenons les dépendances (je vais me concentrer sur la partie importante):
  
  
  
  • django-cms==3.4.4 nécessite django<1.11,>=1.8
  
  
  • django nécessite pytz , mais pas django==1.11.6
  
  
• Nous fusionnons le spécificateur de dépendances ensemble:
  
  
  
  • Nous avons maintenant besoin de django <1.11,>=1.8 (bien mieux ...)
  
  
• Les contraintes ont changé, retour à la sélection du candidat.
• Essayez de trouver un candidat pour django soit <1.11,>=1.8 :
  
  
  
  • Sélectionne un nouveau candidat django , probablement django==1.10.8
  
  
• Calcule les dépendances, continue et résout avec bonheur.

Que faire d'ici?

Eh bien, la suppression du self.requirements.values() du retour dans _prepare_file résout ce problème, je peux le confirmer. Malheureusement, je n'ai pas compris exactement pourquoi il a été ajouté ici.

Peut-être que Kenneth voulait retourner un objet InstallRequirement pour le candidat lui-même après avoir effectué une opération dessus afin d'obtenir des informations liées à la "résolution des extras profonds" (je vais vraiment sur un bout droit ici). Je pourrais essayer de patcher le correctif pour conserver cet objet InstallRequirement supplémentaire dans la valeur renvoyée, mais en le désépinglant d'abord. Je suis presque sûr que ce n'était pas intentionnel, et même si c'était le cas, c'est cassé.

Je pense que c'est ça. ☕️

@vphilippon , merci beaucoup d'avoir fait une ventilation aussi détaillée! Cela clarifie définitivement les choses pour moi.

En parcourant le journal de validation, cela a été ajouté dans ae4591b2 et comme vous l'avez dit, on ne sait pas vraiment pourquoi cela a été ajouté. Je pense que la prochaine étape est de rassembler un cas de test défaillant pour cela, et un cas de test fonctionnel pour installer des "dépendances profondes". Il n'y a aucun ticket qui soulève ce problème et les messages de validation ne sont pas utiles, donc nous sommes juste en train de deviner à ce stade.

En regardant le code, je pense que cela essaie de résoudre une déclaration comme requests[security] qui peut avoir une dépendance certifi[some-extra] qui doit également être résolue. C'est la seule chose à laquelle je peux au moins penser. Je parie qu'il y a quelque chose dans l'univers Django qui fait ça, et si nous pouvons trouver un exemple qui nous permettra d'écrire un test.

Alors! Si quelqu'un souhaite travailler sur la mise en place de ces tests, s'assurer que le premier échoue et que la «dépendance profonde» fonctionne, nous pouvons envisager de supprimer la déclaration self.requirements.values() .

@nateprewitt Voici quelque chose qui, je pense, décrit ce que vous vouliez dire:
https://github.com/vphilippon/testdeepextra

Mais, la résolution profonde "toto [a] dépend de la barre [b]" semble être déjà correcte dans pip-tools , car elle peut être testée avec ce dépôt.
Donc, ce patch n'est peut-être pas exactement cela, car je suppose que c'est pour quelque chose qui ne fonctionnait pas à l'origine dans pip-tools . Sauf si c'est pour un cas spécifique, je n'ai pas pu tester ici.

Quoi qu'il en soit, nous pouvons toujours tester le comportement de résolution de l'extra de pipenv avec ce repo (ce que je n'ai pas le temps de faire tout de suite), avec et sans ce patch, et voir si cela a un effet, et / ou comparer avec la sortie de pip-tools . Au moins, nous avons un point de départ.

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. J'ai eu cette erreur lorsque la version du paquet était égale à '*' ， mais lorsque je la change pour la version connue, telle que '== 0.1.2', cela fonctionne bien.
2. Malheureusement, lorsque je tape pipenv install sanic-plugins-framework==0.5.0.dev20171225 , je reçois ce gros message d'erreur. Peut-être que toute la version ci-dessus n'est pas supérieure à '0.5.0.dev20171225'
3. Comment dois-je faire pour couvrir cela

pipenv lock —pre —clear

Merci @Jasonsey pour votre contribution et
J'ai eu un problème spécifiquement avec sanic-plugins-framework , et l'ajout de l'indicateur --pre (_Allow pre-releases._ flag) m'a aidé à installer le package 🙌

Cela a-t-il déjà été réglé? J'ai toujours le même comportement erroné.
https://github.com/pypa/pipfile/issues/114