Pip: `pip install -U` actualiza las dependencias ya satisfechas

En mi opinión, es un comportamiento conocido, no sé si realmente es un error, supongo que easy_install tiene el mismo comportamiento.

Me gustaría ver las opiniones de los demás.

PD: Hubo una pregunta en StackOverflow relacionada con esto: http://stackoverflow.com/questions/5937756/why-is-pip-looking-for-download-cache-if-the-same-exact-package-is -ya-instaló

Relacionado con el número 49

Es un error y es un duplicado del # 49.

No creo que sea un duplicado del número 49. Leí el # 49 diciendo que install -U foo no debería reinstalar _ foo mismo_ si ya está en la última versión, que es diferente de si debería o no reinstalar foo dependencias ya satisfechas.

Esta distinción es importante para las bibliotecas difíciles de construir que tienen lanzamientos frecuentes pero API bastante estables; en su mayor parte, una instalación es lo suficientemente buena; solo querría reinstalarla si mis dependencias comienzan a usar características más nuevas de esas dependencias anidadas (es decir, si el requisito ya no se cumple), por ejemplo:

• foo 0.1 depende de lxml>=2.3.0
• foo 0.2 se libera y depende de lxml>=2.3.0 (misma dependencia)
• lxml 2.4.0 se libera

Si ya instalé foo 0.1 y lxml 2.3.0 , y pip install -U foo , no querría que instalara lxml 2.4.0 . Solo debería instalar lxml 2.4.0 cuando foo comience a depender de lxml>=2.4.0 .

Ah, sí, eso es un poco diferente. Incluso si el # 49 es fijo, se necesitaría algún código adicional para lograr el comportamiento que desea cuando la dependencia no está en su última versión, pero aún cumple con los requisitos de dependencia.

Creo que si hiciéramos este cambio, algunas personas lo encontrarían sorprendente. Puedo ver por qué es deseable en ciertos casos, pero también puedo ver casos en los que el comportamiento actual (menos # 49) es preferible. Así que estoy indeciso en este caso.

¿Sería apropiada una opción de línea de comandos adicional? pip install foo --upgrade frente a pip install foo --upgrade-recursive ? (O --upgrade-nonrecursive si es importante preservar el comportamiento actual de manera compatible con versiones anteriores)

hacer que las actualizaciones no sean recursivas de forma predeterminada proporcionaría coherencia con otros administradores de paquetes, como APT y Portage. y creo que hay una buena razón para tal comportamiento, que es que evita efectos secundarios no deseados: si quiero actualizar un paquete P, entonces me gustaría ingresar un comando en la línea de upgrade P , no upgrade P --but-not-other-things .

por otro lado, creo que un comando "actualizar todo" (ver # 59) debería ser recursivo por defecto, ya que "todos" debería significar realmente "todos" por defecto. en este caso, el comportamiento no recursivo significaría "actualizar todos los paquetes instalados directamente, pero no las dependencias que no se instalaron directamente" (como emerge --update @world Portage sin --deep ).

Un problema relacionado es que si el paquete que se actualiza depende de otro paquete que ya está instalado pero no está disponible en un repositorio, Pip fallará y no podrá actualizar el paquete solicitado, a pesar de que se cumplan sus dependencias.

Esto parece suceder tanto con -I como con -U.

Dado que -I representa --ignore-installed , y está destinado a hacer que pip funcione como si no hubiera nada instalado, reinstalar todo es el comportamiento correcto para -I . Por lo tanto, el comportamiento aquí es solo un error para -U , no para -I .

easy_install no tiene el mismo comportamiento. easy_install no reinstalará las dependencias si ya se cumplen.

esto no es una característica o comportamiento, esto es un error.

esto también es realmente molesto: probar la distribución PIP para el paquete de un marco, o actualizar un único complemento del marco, significa tener que volver a instalar el marco completo y todas sus dependencias. estas descargas e instalaciones innecesarias son una pérdida de tiempo y recursos.

para aquellos que solo quieren una forma de hacer esto _ahora_, salvo un cambio de comportamiento / código a "-U"

Creo que esto logra el resultado deseado, ¿verdad?

actualizar solo los requisitos de nivel superior:

• pip install -U --no-deps REQS // actualiza solo el nivel superior
• pip install REQS // esta segunda pasada instalará cualquier _new_ dependencias de la actualización

Para el caso más simple, eso es suficiente, pero no creo que eso funcione para un archivo requirements.txt, o si hay dependencias que tienen actualizaciones para sus install_requires. Tenemos un script complicado que difiere de nuestros requisitos.txt y más o menos hace lo que usted describe, pero no maneja la profundidad de actualización> 1.

Lo que complica las cosas hasta cierto punto es que muchos paquetes de django comentan o eliminan sus líneas install_requires debido a este error; de lo contrario, terminan con alguna versión alfa de django instalada (esa ha sido nuestra experiencia, y la he visto en los problemas de github de muchos paquetes destacados de django.

Hola @fdintino ,

para el caso en el que un requisito de nivel superior tiene una nueva dependencia "install_requires", es por eso que mencioné el comando de segundo paso para instalarlos.

para el caso en el que "hay dependencias que tienen actualizaciones para sus install_requires", no estoy seguro de seguirlo allí. solo descubriría y querría actuar sobre eso, si quisiera hacer una actualización recursiva completa, ¿verdad?

Solo si ya no cumple con los requisitos. Entonces, por ejemplo, si actualicé django-sentry, y django-sentry requirió django-celery>=2.5.4,django-celery<3.0 donde anteriormente requería django-celery>=2.5.3,django-celery<3.0 (tal vez debido a una corrección de errores o una nueva característica), y actualmente tengo django-celery==2.5.3 , entonces esperaría que actualizara django-celery para satisfacer el requisito, como lo hace mi parche. Sin embargo, si tuviera django-celery==2.5.4 , no esperaría que actualizara el apio. En el caso del apio no es gran cosa, pero cuando los paquetes tienen Django>1.2,Django<=1.4 , y los proyectos a menudo se escriben para apuntar a Django 1.2, 1.3 o 1.4, una actualización inesperada de django puede ser un gran dolor de cabeza.

gracias @fdintino . Yo sigo ahora. no desea cortar todo comportamiento recursivo (que hará las actualizaciones necesarias para cumplir con los requisitos), solo desea detener las actualizaciones "forzadas" recursivas.

por cierto, su comentario se recorta debido al formato. podría querer arreglar eso para otros.

Publiqué una esencia que analiza el logro del comportamiento deseado utilizando los 2 comandos en secuencia mencionados anteriormente.
No es que invalide el deseo de este boleto o el tirón, pero fue útil para mí confirmar cómo
funciona actualmente y lo que es posible actualmente.
(pista: en el ejemplo, "b" es el paralelo a django que se mencionó como una preocupación)

https://gist.github.com/3088149

comentario apreciado en la esencia si este no es el escenario.

Noto que esto ha estado abierto mucho tiempo.

Descubrí que mi versión de pip ahora tiene la opción de hacer

pip install --upgrade --upgrade-strategy=only-if-needed package

Este parece ser el comportamiento deseado, aunque bastante detallado. Personalmente, creo que hubiera sido genial si este fuera el predeterminado, pero tal vez sea demasiado tarde para cambiar ahora.

Si es demasiado tarde para cambiar el valor predeterminado, creo que esto se puede cerrar.

En https://github.com/pypa/pip/issues/3871#issuecomment -247789343 mencioné lo que creo que es la forma en que vamos a avanzar en esto, reproduciendo aquí:

Volviendo a esto ahora. Esto es lo que creo que deberíamos hacer:

1. Agregue --upgrade-strategy = [ansioso / no ansioso] en pip vX, que por defecto es eager , y permita a las personas optar por la estrategia de no ansioso. Esto nos permitirá obtener algunas pruebas del mundo real de personas sin forzar un cambio en todos a la vez.
2. Una vez que hayamos abordado cualquier comentario de 1., cambie el valor predeterminado de --upgrade-strategy a non-eager en pip vX + 1. Esto nos dará mucho uso en el mundo real al forzar un cambio a todos, pero les da una vía de escape a las personas que, por cualquier razón, se ven afectadas por el cambio.
3. Una vez que hayamos abordado cualquier comentario de 2., observe la desaprobación de --upgrade-strategy en pip vx + 2 (que se eliminará siguiendo nuestra política de depreciación normal).

Esto tendrá un tiempo de espera más largo antes de que no ansioso sea el valor predeterminado, pero nos permite graduarlo más lentamente para asegurarnos de que no haya ningún caso de uso que se vaya a perder. Idealmente, creo que nos gustaría deshacernos eventualmente de la bandera --upgrade-strategy . Ese tipo de bandera se siente como si solo estuviera buscando problemas con las cosas que se rompen porque esencialmente requiere que dupliquemos nuestras pruebas de actualización para probar las cosas por completo. Sin embargo, creo que es una buena bandera para agregar por ahora, para permitir la entrada gradual y lidiar con cualquier rotura.

Vale, suena bien, esperaré a que se complete el paso 2. Parece que el otro tema es un duplicado, pero ya está cerrado.

@xavfernandez @dstufft ¿Se puede cerrar esto o esperaremos hasta que los cambios predeterminados?

Probablemente esperaremos hasta que los cambios predeterminados.

Clausura, desde que se fusionó # 4500