En mi caso nunca terminó. El motivo fue actualizar djangorestframework a una versión incompatible con django . Quería que instalara djangorestframework-3.12.4 , que depende de django >= 2.2 , y también tenía django==2.0.2 en requirements.txt .

Rebaje su pip a la versión 20.x, este es el problema que enfrentará en la versión 21.x de pip

Tuve un problema similar y quería informar la solución que funcionó para mí. Tuve que actualizar la versión pip usando

 pip install --upgrade pip

En realidad, estaba creando una imagen acoplable, así que agregué la línea

 RUN pip install --upgrade pip

Justo antes de instalar los requisitos. En el momento de escribir esta respuesta, la versión pip instalada es 22.0.3 . Hacerlo solucionó el problema.

A pesar de que todos mis paquetes en requirements.txt tenían una versión corregida, el problema seguía presente. Simplemente los actualicé a sus últimas versiones en su lugar. Por supuesto, esto trae un esfuerzo adicional para garantizar que nada se rompa, pero pareció resolver el problema para mí.

Entonces están cambiando el resolver, esto parece ser un error. Lo que funcionó fue usar el viejo resolver, usando la bandera

 --use-deprecated=legacy-resolver

Esto funcionará hasta pip 21.0 aparentemente.

fuente https://github.com/pypa/pip/issues/9215

He fijado todas mis dependencias. Tendrás que fijarlos más tarde o ahora, así que es mejor hacerlo ahora. estoy en pip 20.3.1

Si no fijamos ninguna de nuestras dependencias, el nuevo algoritmo de resolución de dependencias comprueba todas las versiones disponibles con cada dependencia, desde la última hasta las etiquetas de la versión inicial.

Última actualización (2022-02)

Parece que hay una actualización importante en pip solo unos días (versión 22.0 , notas de la versión + problema relevante en github ).

No lo he probado con más detalle, pero realmente me parece que optimizaron el cálculo del orden de instalación en casos complejos de tal manera que resuelve muchos problemas que todos encontramos anteriormente. Pero necesitaré más tiempo para comprobarlo.

De todos modos, el resto de esta respuesta sigue siendo válida y la fijación de requisitos inteligentes adecuada para un proyecto en particular es una buena práctica, en mi opinión.

Dado que encontré un problema similar, estoy de acuerdo en que esto es bastante molesto. El retroceso puede ser una función útil, pero no desea esperar horas para completar con un éxito incierto.

Encontré varias opciones que podrían ayudar:

• Use el antiguo resolver ( --use-deprecated=legacy-resolver ) propuesto en la respuesta por @Daniel Davee , pero esto es más una solución temporal que una adecuada.
• Omita la resolución de dependencias con --no-deps . No recomendaría esto en general, pero en algunos casos puede tener un conjunto funcional de versiones de paquetes, aunque existen algunos conflictos.
• Reduzca la cantidad de versiones que pip intentará dar marcha atrás y sea más estricto con las dependencias de los paquetes. Esto significa que en lugar de poner, por ejemplo numpy en mis requisitos.txt, podría probar numpy >= 1.18.0 o ser aún más estricto con numpy == 1.18.0 . El rigor puede ayudar mucho.

Consulta las siguientes fuentes:

• Arreglando conflictos
• Discusión de pip de Github
• Reducir el retroceso

Todavía no tengo una respuesta adecuada que siempre ayude, pero la mejor práctica para los requisitos.txt parece "fijar" las versiones del paquete. Encontré pip-tools que podrían ayudarlo a manejar esto incluso con constrains.txt (pero estoy en una fase experimental, así que no puedo contarles más).

Actualización (2021-04)

Parece que el autor de la pregunta pudo solucionar el problema (algo con el servidor gitlab personalizado), pero me gustaría ampliar esta respuesta, ya que podría ser útil para otros.

Después de leer y probar, terminé anclando todas las versiones de mi paquete a una específica. Esto realmente debería ser la forma correcta. Aunque todo aún puede funcionar sin él, puede haber casos en los que si no fija sus dependencias, su administrador de paquetes instalará silenciosamente una nueva versión (cuando se publique) con posibles errores o incompatibilidad (esto me sucede con dask last this año).

Hay varias herramientas que pueden ayudarlo, recomendaría uno de estos enfoques:

El más fácil con pipreqs

• pipreqs es una biblioteca que genera un archivo pip requirements.txt basado en las importaciones de cualquier proyecto
• puede comenzar con pip install pipreqs y ejecutar solo pipreqs en la raíz de su proyecto (o eventualmente con --force flag si sus requisitos ya existen)
• creará fácilmente requirements.txt con versiones ancladas basadas en importaciones en su proyecto y versiones tomadas de su entorno
• entonces puede crear un nuevo entorno en cualquier momento basado en estos requirements.txt

Esta es una herramienta realmente simple (incluso no necesita escribir sus requisitos.txt). No te permite crear algo complejo (puede que no sea una buena opción para proyectos más grandes), la semana pasada encontré un comportamiento extraño (ver esto ) pero en general estoy contento con esta herramienta ya que suele funcionar perfectamente.

Usando pip-tools

Hay varias otras herramientas de uso común como pip-tools , Pipenv o Poetry . Puede leer más en Compilaciones más rápidas de Docker con pipenv, poesía o pip-tools o Python Application Dependency Management en 2018 (más antiguo pero aún me parece válido). Y todavía me parece que la mejor opción (aunque depende de su proyecto/caso de uso) es pip-tools .

Puede (esta es una opción, vea más en los documentos ):

• cree requirements.in (el mismo formato que requirements.txt , depende de usted si fija alguna dependencia del paquete o no)
• luego puede usarlo pip install pip-tools y ejecutar pip-compile requirements.in
• esto generará un nuevo archivo requirements.txt donde se fijan todas las versiones, está claro cuál es el origen
• (Opcionalmente) puede ejecutarlo con la opción --generate-hashes
• entonces puede (como con pipreqs ) en cualquier momento crear un nuevo entorno basado en estos requirements.txt
• pip-tools le ofrece la opción --upgrade para actualizar los requisitos finales
• admite requisitos en capas (por ejemplo, tener versiones de desarrollo y producción)
• hay integración con compromiso previo
• ofrece una herramienta pip-sync para actualizar su entorno según los requisitos.txt

Hay algunas cosas más que puedes hacer con él y realmente me encanta la integración con pre-commit . Esto le permite usar los mismos requisitos que antes (solo con el sufijo .in ) y agregar un gancho de confirmación previa que actualiza automáticamente los requirements.txt (por lo que nunca experimentará tener un entorno local diferente al de los requirements.txt generados, lo que podría suceder fácilmente cuando ejecutas algo manualmente).