Pipenv: No se pudieron resolver las dependencias. ¿Regresión?

Parece que pipenv agrega un pin estricto a los candidatos de la ronda actual.

Esto significa que si en una próxima ronda, otro paquete requiere una versión que no coincide con el candidato actual, fallará (así) en lugar de intentar encontrar otro candidato. Así es como funciona el algoritmo de resolución: vuelva a calcular por completo con las nuevas restricciones hasta que se estabilice.

No estoy seguro de qué está causando esto.
Me di cuenta de que para reproducir esto, tengo que borrar el caché ( --clear ) si usé pip-tools solo antes.
Puedo decir que esto no es un error de pip-tools , y no está directamente relacionado con los parches de pip-tools (los eliminé todos para probar, y esto aún ocurre).
Espero que esto ayude.

Muy bien, encontré al culpable:
https://github.com/kennethreitz/pipenv/blob/master/pipenv/patched/pip/req/req_set.py#L752

self.requirements.values() contiene el req_to_install sí mismo, fijado, que es incorrecto devolver como una dependencia y puede hacer que la resolución de la dependencia falle, como aquí, si un paquete posterior requiere una versión que no se ajusta al candidato actual. Hacer esto supone que nuestro primer candidato debe ser el correcto o fallar.

@kennethreitz Por lo que tengo entendido, eso fue hacer "resolución de extras profundos". No estoy seguro de entender qué se supone que significa eso exactamente. Estoy listo para seguir apuñalando esto, pero necesito información para no ir en la dirección equivocada.

Creo que estoy viendo el mismo problema:

$ 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

donde 2.0a1 es claramente una de las opciones disponibles.

No puedo probar la resolución de dependencias en versiones anteriores de pipenv debido a https://github.com/kennethreitz/pipenv/issues/786. En mi opinión, las correcciones de errores críticos deben aplicarse al menos a algunas de las versiones principales más recientes.

El mismo problema: se queja específicamente de las solicitudes.

Este es un error que creo que está relacionado con el comentario de @vphilippon . Sin embargo, no creo que esté relacionado con el número 909.

Exacto, no relacionado con el # 909.
Como dije, necesitaré la información de uno de los @maintainers para comprender qué significa exactamente aquí "resolución profunda de extras". Tengo una solución, pero me gustaría saber más para no romper nada primero.

O podría seguir adelante y abrir un PR con la solución y discutir allí. Veré con mi tiempo libre.

@vphilippon Dado que no se trata de una organización, sino de un repositorio personal de Kenneth, desafortunadamente no tenemos una etiqueta @ útil para todos nosotros. Sugeriría hacer ping a @erinxocon y a mí.

Desafortunadamente, el parche para picar aquí está guardado en algún lugar de la cabeza de Kenneth. No creo que entiendo, o no he tenido tiempo de mirar, lo que está pasando aquí. Si encuentra algo de tiempo para compilar lo que cree que puede estar sucediendo, puedo intentar ayudar a verificar las suposiciones. Sin embargo, hasta entonces, esto es algo que tendremos que andar con cuidado antes de realizar cambios.

@nateprewitt Muy bien ,

¿Qué pasa?

En https://github.com/kennethreitz/pipenv/issues/875#issuecomment -335570812, noté la fuente del error: los candidatos seleccionados en una ronda de resolución se agregan como dependencia fijada del candidato en sí directamente, lo cual es incorrecto ( más sobre eso que viene)

En https://github.com/kennethreitz/pipenv/issues/875#issuecomment -336609268, encontré la fuente de ese pin: el self.requirements.values() que se agregó al valor de devolución incluye un pin al paquete actual . En otras palabras, _prepare_file debería devolver las dependencias de un paquete (o "Una lista de requisitos de instalación adicionales para instalar también"), pero ahora se incluye a sí mismo, anclado, como su propia dependencia.

Para ayudar a demostrar por qué tener el paquete en sí, anclado, como su propia dependencia, es realmente incorrecto, así es como funciona el algoritmo de resolución de dependencias, en resumen:

1. Obtenga initial_constraints_set , una lista de InstallRequirements (ex: requests>=2.18 ).
2. Defina additional_constraints y candidate como conjunto vacío.
3. Seleccione un conjunto de candidate (ex: requests==2.18.4 ) que respeten la unión de initial_constraints_set y additional_constraints
4. Para cada candidato, obtenga y combine el conjunto de dependencias de todos los candidatos, como additional_constraints (ex: certifi>=2017.4.17 )
5. Si additional_constraints ha cambiado, borre candidate y vuelva a 3.
6. Devuelve el conjunto de candidatos, listo.

Ahora, reproduzcamos el problema con lo anterior en mente.

Para reproducir el problema, necesita esto Pipfile (porque se lanzó `django-cms 3.4.5 con soporte Django 1.11):

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

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

Y ahora 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 una sola ronda de resolución, detectamos que tenemos que instalar django==* y django-cms==3.4.4 .
• Seleccionamos candidato: django==1.11.6 , django-cms==3.4.4 .
• Obtenemos las dependencias (me centraré en la parte importante):
  
  
  
  • django-cms==3.4.4 requiere django<1.11,>=1.8
  
  
  • django requiere django==1.11.6 (¡Esto no es cierto, django no se requiere a sí mismo! ¡Ningún paquete se requiere a sí mismo!)
  
  
• Fusionamos el especificador de dependencias:
  
  
  
  • Ahora requerimos django <1.11,==1.11.6,>=1.8 (Puede ver a dónde va esto ...)
  
  
• Las restricciones han cambiado, volviendo a la selección de candidatos.
• Intenta encontrar un candidato para django que sea <1.11,==1.11.6,>=1.8 :
  
  
  
  • Could not find a version that matches django<1.11,==1.11.6,>=1.8 [...]
  
  

Qué debería haber sucedido (como sucede en pip-tools , con un pip sin parche, con --rebuild para borrar el caché):

• En una sola ronda de resolución, detectamos que tenemos que instalar django==* y django-cms==3.4.4 .
• Seleccionamos candidato: django==1.11.6 , django-cms==3.4.4 .
• Obtenemos las dependencias (me centraré en la parte importante):
  
  
  
  • django-cms==3.4.4 requiere django<1.11,>=1.8
  
  
  • django requiere pytz , pero no django==1.11.6
  
  
• Fusionamos el especificador de dependencias:
  
  
  
  • Ahora requerimos django <1.11,>=1.8 (Mucho mejor ...)
  
  
• Las restricciones han cambiado, volviendo a la selección de candidatos.
• Trate de encontrar un candidato para django que sea <1.11,>=1.8 :
  
  
  
  • Selecciona un nuevo candidato django , probablemente django==1.10.8
  
  
• Calcula dependencias, continúa y se resuelve felizmente.

Que hacer desde aqui

Bueno, eliminar el self.requirements.values() de la devolución en _prepare_file soluciona este problema, puedo confirmarlo. Desafortunadamente, no he descubierto exactamente por qué se agregó allí.

Tal vez Kenneth quería devolver un objeto InstallRequirement para el propio candidato después de realizar alguna operación en él para obtener información relacionada con la "resolución de extras profundos" (realmente me voy a extender aquí). Podría intentar parchear el parche para mantener ese objeto adicional InstallRequirement en el valor devuelto, pero desanclarlo primero. Estoy bastante seguro de que no fue intencional, e incluso si lo fuera, está roto.

Creo que eso es todo. ☕️

@vphilippon , ¡muchas gracias por poner un desglose tan detallado! Esto definitivamente me aclara las cosas.

Examinando el registro de confirmación, esto se agregó en ae4591b2 y, como ha dicho, no está muy claro por qué se agregó. Creo que el siguiente paso es armar un caso de prueba fallido para esto y un caso de prueba funcional para instalar "dependencias profundas". No hay tickets que mencionen este problema y los mensajes de confirmación no son útiles, por lo que solo estamos adivinando en este punto.

Mirando el código, creo que esto está tratando de resolver tener una declaración como requests[security] que puede tener una dependencia certifi[some-extra] que también debe resolverse. Eso es lo único en lo que puedo pensar al menos. Apuesto a que hay algo en el universo de Django que está haciendo esto, y si podemos encontrar un ejemplo que nos permita escribir una prueba.

¡Entonces! Si alguien quisiera trabajar para poner estas pruebas juntas, asegurándose de que la primera falla y la "dependencia profunda" funcione, podemos considerar eliminar la declaración self.requirements.values() .

@nateprewitt Aquí hay algo que creo que describe lo que quisiste decir:
https://github.com/vphilippon/testdeepextra

Pero, la resolución profunda "foo [a] depende de la barra [b]" parece estar ya bien en pip-tools , ya que se puede probar con ese repositorio.
Entonces, ese parche podría no ser exactamente eso, ya que supongo que es para algo que originalmente no funcionaba en pip-tools . A menos que sea para algún caso específico, no pude probar aquí.

De todos modos, todavía podemos probar el comportamiento de resolución adicional de pipenv con ese repositorio (que no tengo tiempo para hacer de inmediato), con y sin ese parche, y ver si tiene algún efecto, y / o compare con la salida de pip-tools . Al menos tenemos un punto de partida.

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. Recibí este error cuando la versión de los paquetes es igual a '*', pero cuando lo cambio a la versión conocida, como '== 0.1.2', funciona bien.
2. Desafortunadamente, cuando escribo pipenv install sanic-plugins-framework==0.5.0.dev20171225 , recibí este gran mensaje de error. Quizás toda la versión anterior no sea mayor que '0.5.0.dev20171225'
3. ¿Cómo debo hacer para cubrir esto?

pipenv lock —pre —clear

Gracias @Jasonsey por compartir tu parte y a @techalchemy por tu respuesta.
Tuve un problema específicamente con sanic-plugins-framework , y agregar la bandera --pre (_Permitir prelanzamientos._) me ayudó a instalar el paquete 🙌

¿Se arregló esto alguna vez? Sigo teniendo el mismo comportamiento erróneo.
https://github.com/pypa/pipfile/issues/114