Pip: Nuevo solucionador: lanzamiento, bucles de retroalimentación y flujo de desarrollo

No sé cómo lo tiene planeado, pero un comentario es que lo alentaría a que intente compartir el código tanto como sea posible entre el código nuevo y el código actual, y refactorice el código actual a medida que trabaja para permitir un mayor intercambio entre las rutas de código nuevas y actuales.

Una de las razones es que si está compartiendo más código, habrá menos posibilidades de que se rompa cuando active y desactive el nuevo comportamiento, porque estará ejercitando ese código compartido en ambos estados y no tendrá tanto muchas diferencias potenciales en el comportamiento con las que lidiar.

Esto implicaría CTA a los usuarios para pedirles que lo prueben y proporcionen comentarios.

Nuestro historial de recibir comentarios anticipados sobre nuevas características ha sido bastante malo. Probamos versiones beta, lanzamos nuevas funciones con banderas de "exclusión voluntaria" que las personas pueden usar si encuentran problemas, grandes campañas publicitarias para cambios importantes, y ninguno de ellos parece haber funcionado.

Mi sensación personal es que "hacer que esté disponible y pedir comentarios" es una variación interesante de lo que hemos intentado anteriormente, pero en última instancia no hará mucha diferencia. Demasiadas personas usan el último pip con opciones predeterminadas en sus canalizaciones de compilación automatizadas y no prueban antes de pasar a una nueva versión de pip (vimos esto con PEP 517).

Me pregunto: ¿podríamos obtener una subvención de PSF para obtener recursos para hacer un gran ejercicio de prueba del "mundo real" para esta función o (mejor aún) desarrollar una infraestructura de prueba para nosotros? Dicho proyecto podría incluir una convocatoria de proyectos para informarnos sus flujos de trabajo y configuraciones, de modo que podamos establecer rutas de prueba que aseguren que las nuevas versiones de pip no las rompan. ¿O simplemente usar una subvención para conseguir a alguien con experiencia en el aspecto de las comunicaciones para obtener probadores beta de nuevas funciones que nos ayuden a configurar un mejor programa de prueba de usuarios?

En términos de git/GitHub, esta es probablemente la primera implementación de funciones "experimental" dentro de pip

No estoy 100% seguro de lo que quieres decir con eso. Ciertamente hemos tenido nuevas funciones en el pasado que se han agregado mientras la "manera antigua" todavía estaba presente. No solemos dejarlos "desactivados de forma predeterminada, habilítelos para probarlos", si eso es lo que quiere decir, pero eso se debe principalmente a que nunca hemos encontrado una buena manera de obtener comentarios (ver arriba).

Pasé ~ 60 minutos (re-re-re-re-re-)escribiendo esta publicación, ¡así que ahora voy a echar un vistazo a los lugares en Nueva York! Si no ves una respuesta rápida de mi parte es porque estaré en modo turista.

Lo alentaría a que intente compartir el código tanto como sea posible entre el código nuevo y el código actual, y refactorice el código actual a medida que trabaja para permitir un mayor intercambio entre las rutas de código nuevas y actuales.

¡Definitivamente! Este es el 80% de por qué estoy poniendo #5051 por delante de esto: tengo la intención de pagar una gran parte de la deuda técnica que hemos acumulado en nuestra lógica de compilación para que sea más fácil reutilizarlo (¿todo?). Un montón del código tendrá que ser :fuego: y estoy de acuerdo en que el resto definitivamente debería reutilizarse tanto como sea razonable.

No solemos dejarlos "desactivados de forma predeterminada, habilítelos para probarlos", si eso es lo que quiere decir

Sí, de hecho. También estoy insinuando el flujo de desarrollo aquí: en mi opinión, estaría bien fusionar la infraestructura vacía (clases con un montón de métodos que son solo raise NotImplementedError() que se desarrollarán en PR posteriores) o uno no cubra todos los casos (implementación a medias) en la rama master siempre que solo se use detrás de la bandera que se indica explícitamente como "experimental/alfa".

re: comentarios

Soy joven, tonto y optimista. Quiero que este lanzamiento sea una opción para recibir comentarios proactivos y actuar en consecuencia. Por "proactivo", me refiero a personas que están dispuestas a tomarse un tiempo extra para probar la funcionalidad alfa/beta e informarnos sobre cómo es. Creo que si hacemos suficiente ruido y nos dirigimos/llegamos estratégicamente a las personas, podemos obtener buenos comentarios "proactivos" de personas que tienen el tiempo y la energía para probar nuevas funciones para ayudar a resolver los detalles/problemas.

Al observar nuestros cambios "importantes" recientes, creo que la mayoría de los comentarios que recibimos fueron reactivos, de usuarios que se dieron cuenta de problemas con sus flujos de trabajo cuando fallaron y luego se comunicaron con nosotros para informarnos al respecto. Es posible que muchos de ellos no hayan tenido tiempo para ayudar a resolver los detalles de la nueva funcionalidad, lo que genera mucha fricción. Estos también nos cuestan mucho de nuestro "presupuesto de abandono" [1], que no quiero gastar más, ya que Python Packaging realmente no tiene mucho más de todos modos [2].

FWIW, planeo tomar prestadas algunas ideas del lanzamiento de PyPI, como hacer publicaciones de blog en ubicaciones bastante visibles (es decir, no en mi blog personal), posiblemente publicar podcasts, correos electrónicos procesables en el momento oportuno, etc. También estoy buscando más arte anterior /vías para comunicarse vía. Una de las (¡muchas!) cosas que aprendí en PyCon fue que hay canales que no usamos, que ayudarán a difundir información pero no buscarán verificar si tenemos alguno para difundir.

Para ser claros, no estoy criticando el enfoque de implementación que tomamos para PEP 517, creo que va bien, especialmente dado que todos somos voluntarios. Estoy tratando de ver lo que podemos aprender y los elementos procesables para tratar de evitar los problemas que tuvimos. La mayoría de estos elementos implican más trabajo por parte de los mantenedores y la razón principal por la que paso todo este tiempo pensando en esto es porque lo veo como un divertido ejercicio de aprendizaje sobre cómo hacer la gestión del cambio.

re: subvenciones

Sí, creo que definitivamente podemos usar una subvención o una persona con más experiencia para ayudarnos a descubrir la comunicación, los despliegues y la infraestructura de prueba. Sin embargo, eso necesita a alguien que haga el trabajo de redacción de subvenciones y descubra planes más concretos de los que puedo hacer en este momento, ya que no tengo una cantidad más estable de horas por semana que pueda garantizar.

FWIW, PSF tiene un contrato en curso para ayudar a descubrir la comunicación relacionada con PyPA/Packaging con Changeset Consulting, entonces, ¿quizás podamos aprovechar eso?

Intencionalmente no estoy @-mencionando personas ya que esto es bastante temprano en el estado de planificación para agregar más personas a la conversación.

Notas al pie:

1. Un término muy agradable que usó @pganssle y que definitivamente voy a usar.
2. Esta es la razón por la que puse el n.º 3164 en un segundo plano, a pesar de tener una implementación del paquete "pip-cli" propuesto allí y tener un consenso razonable sobre cómo queremos que se vea la implementación.

Soy joven, tonto y optimista.

:-) Y a veces soy demasiado viejo, cansado y cínico. Vamos con tu filosofía, suena mucho mejor :-)

¡Definitivamente! Este es el 80% de por qué estoy poniendo #5051 por delante de esto: tengo la intención de pagar una gran parte de la deuda técnica que hemos acumulado en nuestra lógica de compilación para que sea más fácil reutilizarlo (¿todo?).

¡Estupendo!

Desde IRC hace un momento :

[sumanah] pradyunsg: ¿hay algo que la comunidad de pip & packaging podamos hacer para ayudarlo a hacer más trabajo más rápido en el resolver?
....
[pradyunsg] En realidad, en este momento, las entradas en https://github.com/pypa/pip/issues/6536 probablemente me ayudarían a descubrir cómo abordar el trabajo / obtener comentarios de las personas, etc.
....
[sumanah] pradyunsg: re: New Resolver: Lanzamiento, bucles de retroalimentación y flujo de desarrollo #6536 -- la entrada que desea es algo como: ¿es una buena idea el enfoque de indicador de funciones? ¿Es una buena idea obtener comentarios a través de algún mecanismo que no sean los problemas de pip GitHub? ¿Es una buena idea obtener una subvención o algo similar para obtener pruebas manuales del mundo real y una infraestructura de pruebas robusta construida, y/o comunicaciones proactivas?
...
[pradyunsg] Sí, si las ideas que sugiero son buenas. Además, cualquier idea/enfoque/pensamiento adicional que pueda ayudar a que la implementación y los comentarios sean más fluidos sería increíble.

Entonces:

¿Es el enfoque de la bandera característica una buena idea? Si.

¿Es una buena idea obtener comentarios a través de algún mecanismo que no sean los problemas de pip GitHub? Si. Deberíamos encontrar formas automatizadas de aceptar informes de errores menos estructurados de usuarios menos expertos.

¿Ayudaría una infraestructura de prueba más robusta? Sí, mucho, y este es un lugar donde nuestros patrocinadores podrían ayudarnos.

¿Podría Changeset (yo), según el contrato existente con PSF para ayudar con la coordinación/comunicaciones de PyPA, ayudar a pip con comunicaciones proactivas para obtener pruebas manuales más sistemáticas en el mundo real? Suponiendo que me queden horas en mi contrato para cuando queramos comenzar este lanzamiento, sí.

¿Es una buena idea obtener una subvención o algo similar para obtener más ayuda con la experiencia del usuario, las comunicaciones/publicidad y las pruebas? Si. Las subvenciones de PSF serían potencialmente de interés , al igual que las subvenciones de NLNet (para solicitudes de menos de 30 000 euros ), potencialmente la subvención de software de código abierto esencial para ciencia de Chan Zuckerberg y el MOSS de Mozilla . El GT de Envases puede ser el solicitante del registro. Si @pradyunsg o @pfmoore quieren dar un asentimiento de "sí, eso suena interesante", puedo comenzar a investigar esas posibilidades con el grupo de trabajo.

Si @pradyunsg o @pfmoore quieren asentir con un "sí, eso suena interesante",

Definitivamente suena interesante para mí :-)

@pradyunsg o @pfmoore quiere dar un asentimiento de "sí, eso suena interesante"

_asiente_ sí, eso suena interesante

¿Ayudaría una infraestructura de prueba más robusta? Sí, mucho, y este es un lugar donde nuestros patrocinadores podrían ayudarnos.

@brainwane También es relevante aquí https://github.com/pypa/integration-test. Creo que configurar esto es otra área potencial para la financiación. Deberíamos agregar esto a https://wiki.python.org/psf/Fundable%20Packaging%20Improvements.

¡OK! Empecé a hablar con el PSF y con la gente de la Iniciativa Chan Zuckerberg sobre cómo solicitar una subvención CZI a través del Grupo de Trabajo de Empaques. Agregué algunos detalles a la página Mejoras de empaquetado financiables sobre por qué es importante la nueva resolución de pip y agregué el integration-test a esa lista. Y comencé a recopilar nombres de expertos en experiencia del usuario que tienen la capacidad de investigar nuestra complicada cadena de herramientas de instalación/distribución de paquetes en la línea de comandos, hablar con los usuarios para comprender su modelo mental de lo que está sucediendo y lo que debería suceder. y asesorar a los mantenedores.

Si recibimos dinero a través de subvenciones de MOSS, CZI o NLNET, creo que obtendremos el dinero... probablemente en octubre como muy pronto. Una subvención directamente del PSF probablemente sería más rápida, pero "Nuestro enfoque actual son los talleres de Python, las conferencias (especialmente para la ayuda financiera) y los esfuerzos de diversidad/inclusividad de Python".

Una consideración es que sé que Brett y la gente del consejo directivo están hablando de invertir en gestión de proyectos y buscando algún tipo de recursos pagados para gestionar estos proyectos (triaje, gestión de proyectos, etc.) y están hablando con el PSF. directamente. Puede valer la pena comunicarse y averiguar qué están haciendo o pensando, ya que escuché algunas conversaciones sobre sostenibilidad a largo plazo y sería bueno participar en ellas.

Las banderas de características son buenas, las opciones de suscripción son buenas. Una cosa que podría considerar es si podría solicitar a los usuarios aleatoriamente que prueben el resolutor (por ejemplo, con muy, muy poca frecuencia y solo para una instalación a la vez, es decir, sin obligarlos a activarlo de forma permanente). Luego, podría indicar cómo fue útil la resolución (por ejemplo, ¿qué hizo por ellos? ¿Qué conflictos encontró y resolvió?)

Las personas que vienen de javascript o rust, por ejemplo, también esperarán un archivo de bloqueo de algún tipo, por lo que puede ser algo a considerar...

Lamento interrumpir, ¡me alegra ver que esto avanza!

Mi sensación personal es que "hacer que esté disponible y pedir comentarios" es una variación interesante de lo que hemos intentado anteriormente, pero en última instancia no hará mucha diferencia. Demasiadas personas usan el último pip con opciones predeterminadas en sus canalizaciones de compilación automatizadas y no prueban antes de pasar a una nueva versión de pip (vimos esto con PEP 517).

Como una de las personas a las que les molestaron algunos problemas de PEP 517 por este mismo motivo, me encantaría ver una forma de participar para probar las cosas. Pero solo sé sobre este tipo de cosas porque me suscribí a todas las fuentes de noticias de empaquetado de python que pude después del problema de la bandera --no-use-pep517 . Lo que digo es que difundir este tipo de noticias es difícil y probablemente por eso es difícil obtener comentarios.

Creo que más personas estarían interesadas en esto si la información pudiera difundirse mejor. ¿Es eso lo que permitirían los recursos que está buscando?

Para continuar con lo que dice jriddy, también creo que será muy difícil hacer que las personas prueben varios indicadores de características si tienen que conocerlos, realizar cambios en su configuración de CI para cada nuevo indicador, etc.

Lo que parecería mucho más factible, sin embargo, es si solo hay _un_ indicador de función para conocer, para probar "lo que viene a continuación" en términos de cambios que deben probarse. Luego, las personas y las empresas podrían configurar su CI para ejecutar eso también (sin fallar las compilaciones por errores). Estoy pensando en algo similar a Rust, donde este tipo de cambios se hornean en el canal "beta" de la cadena de herramientas, y es fácil configurar otro canal de CI para ejecutar cosas en la cadena de herramientas beta y enviar errores a alguien.

La clave es que esta configuración debe aprenderse y realizarse _solo una vez_, en lugar de tener que aprender continuamente sobre nuevos indicadores de funciones individuales, modificar configuraciones de CI o probarlas manualmente.

Lo que parecería mucho más factible, sin embargo, es si solo hay _un_ indicador de función para conocer,

En cierto sentido, ¿no existe esto ya en forma de --pre ? ¿Podría el canal de lanzamiento beta para pip simplemente ejecutar pip install --upgrade --pre pip ?

Lamento interrumpir, ¡me alegra ver que esto avanza!

@techalchemy por favor, de todas las personas, _usted_ definitivamente no tiene que arrepentirse por participar en esta discusión.

¿Es eso lo que permitirían los recursos que está buscando?

Hasta cierto punto, sí.

reg: versiones beta/"canal" para pip

Gracias por participar en @jriddy y @chrish42. Si bien creo que, en general, definitivamente es una conversación útil/importante, también siento que es un poco OT para este tema. No obstante, responderé aquí una vez; si queremos hablar más de esto, abramos un nuevo tema.

Lo hemos intentado en el pasado, más recientemente con pip 10, pero no ha funcionado bien. También soy un poco escéptico sobre qué tan bien podría funcionar en el futuro, pero también puedo imaginar que algunos cambios en nuestro proceso podrían hacer que esto funcione sin problemas para nosotros. ¿Tal vez podríamos hacer un conjunto de características "solo beta" o algo así? Me imaginé -X all como una sintaxis para eso en #5727. ¿Tal vez podríamos retomar eso como parte de este plan de implementación? No sé. Tendremos que invertir tiempo y energía para resolver esto. :)

Como se menciona en https://github.com/pypa/packaging-problems/issues/25#issuecomment -520167480, creo que es importante tener una explicación consolidada de cómo un solucionador cambia la experiencia de pip. Muchas personas se sentirán frustradas por el cambio a un sistema más rígido (aunque las cosas deberían ser más confiables en general, se bloquearán en lugares donde actualmente no se bloquean).

Tener una explicación central de cómo han cambiado las cosas y por qué es un buen cambio hará que responder a esas personas enojadas sea mucho más simple. Publique un enlace y vea si tienen más preguntas.

La presentación preliminar es una buena idea. En conda, tenemos un canal de prelanzamiento, conda-canary. Alentamos a las personas a configurar un trabajo de CI para que se ejecute contra Canary de una manera que les ayude a ver si los cambios de Conda los van a romper. Idealmente, nos avisan antes de que lancemos esa versión. Ese canal ha sido un fracaso bastante estrepitoso. La única vez que las personas realmente parecen usarlo es cuando quieren obtener la versión más reciente para corregir algún error con el que están luchando. No recibimos muchos informes de nuestros primeros usuarios previstos. Sigo pensando que la presentación preliminar es una buena idea, porque cuando un lanzamiento sale mal y la gente se enoja contigo por romper sus 700 nodos administrados, puedes decir "bueno, estuvo disponible durante una semana antes de que lo lanzáramos. ¿Por qué no ¿Estás probando estas cosas antes de implementarlas en 700 nodos?" Le estás dando a la gente la oportunidad de hacer que las cosas funcionen mejor. Ayúdelos a darse cuenta de que dejar pasar esa oportunidad significa más dolor para ellos en el futuro. Es una inversión que vale la pena para ellos, y si lo hacen como parte de su CI, no les cuesta tiempo aparte de la configuración.

Con respecto a la bandera: creo que es mejor tener una opción de configuración (quizás además de una bandera). No me gustaría pasar una bandera todo el tiempo. No estoy seguro de si pip tiene esta capacidad. ¿Tal vez le digas a las personas que quieren un cambio más permanente que usen el env var correspondiente?

En cuanto a la bandera:

Las opciones de CLI de pip se asignan automáticamente a una opción de archivo de configuración y una variable de entorno, con los nombres apropiados.

@msarahan ¡ Gracias por intervenir, muy apreciado! :)

Con respecto a la opción "déjame hacer lo que quiero" para ignorar las dependencias rotas, creo que sería deseable estructurar el indicador de función de manera que también pueda servir como opción de exclusión después de que el resolver se active de forma predeterminada (por ejemplo, iniciar con --avoid-conflicts como opción de suscripción, eventualmente cambie a --no-avoid-conflicts como opción de exclusión, pero acepte ambas opciones desde el principio)

También querrá considerar cómo --ignore-installed interactúa con el solucionador: cuando se pasa, probablemente debería ignorar todos los requisitos para los paquetes ya instalados.

Más allá de eso, manejar las cosas como parches de refactorización más pequeños para facilitar la integración de la resolución es una excelente manera de hacerlo (ese es el enfoque que hizo posible la nueva API de configuración para CPython: una gran cantidad de refactorización privada que finalmente fue lo suficientemente estable como para hacerla pública)

@ncoghlan ¿Qué significa "optar por no participar" del resolutor? Evitar por completo la resolución de dependencias (y, por lo tanto, la resolución) es --no-deps . Entiendo que existe la necesidad de "ignorar conflictos de versión en este paquete" o algo por el estilo.

Personalmente, no veo ningún sentido en mantener la lógica de resolución "mantener visto primero" por más tiempo que un período de transición a un nuevo resolutor.

Sin embargo, si hay casos de uso que estas dos opciones no cubrirían, realmente me gustaría conocerlos. :)

En términos más generales, si hay flujos de trabajo que tienen problemas con el comportamiento de un resolutor estricto, tengo curiosidad por saber cómo se ven, lo antes posible, para poder averiguar si admitirlos y cómo hacerlo.

Personalmente, no veo ningún sentido en mantener la lógica de resolución "mantener visto primero" por más tiempo que un período de transición a un nuevo resolutor.

IDK, uso esta "característica" para hacer cosas bastante locas con compilaciones, como...

# install just the packages I've built specifically
pip install --no-index --no-deps --find-links=/path/to/my/local/build/cache -r local-reqs.txt

# ...snip to later in a dockerfile, etc...

# install the deps from public PyPI
pip install -r local-reqs.txt

En este caso, le pido que resuelva mis dependencias después de haber instalado algunos paquetes muy predeterminados de una timonera local. Supongo que podría leer mis versiones exactas en ese archivo de requisitos locales para hacer feliz a un resolutor, pero en realidad encontré que el comportamiento actual de pip es bastante útil para permitir este tipo de pasos de inyecciones de compilación arbitrarias. Sin embargo, podría ser un caso del flujo de trabajo de calentamiento de la barra espaciadora , lo admito.

Pero tal vez el comportamiento de "resolución ingenua" todavía tenga un uso.

Estoy de acuerdo con @pradyunsg. No creo que sea viable mantener el código existente y un nuevo resolutor indefinidamente. Ciertamente, como mantenedor de pip, no tengo ningún interés en hacer eso.

Desde el punto de vista de un usuario final, acepto que bien podría haber escenarios extraños en los que el nuevo resolutor podría no hacer lo correcto. Y tener un indicador de emergencia "devuélveme el comportamiento anterior" es un mecanismo de transición importante (aunque es discutible si "volver temporalmente a la versión anterior de pip" no es tan bueno, aunque cosas como el uso común de CI que usa automáticamente el último pip hace que defender esa opción sea problemático). Pero a largo plazo, ¿por qué tendríamos que mantener el comportamiento actual? Puedo imaginar las siguientes situaciones principales:

1. Error de resolución. Posibilidad obvia, solución fácil: corrija el error en la próxima versión de pip.
2. Casos en los que el resolutor anterior es incorrecto (genera resultados que no satisfacen las restricciones). No tenemos la intención de apoyar eso en el futuro, ¿no? (Al menos no a través de algo menos extremo que el usuario fijando lo que quiere y usando --no-deps para apagar el resolver).
3. Casos en los que los resolutores antiguos y nuevos dan resultados diferentes, los cuales satisfacen las restricciones dadas. Los usuarios pueden agregar restricciones para forzar el resultado anterior (si no pueden, eso nos devuelve a (2)). Deberíamos darles tiempo para que lo hagan, pero luego descartar la resolución anterior, como cualquier otra funcionalidad obsoleta.
4. Un caso límite que consideramos demasiado complejo/extraño para soportar. Esto es como (3), pero donde no estamos afirmando que el nuevo resolver da el resultado "correcto". Los usuarios aún pueden modificar las restricciones para evitar el caso extraño, o anclar y usar --no-deps . Pero, en última instancia, decimos "no hagas eso", y si los usuarios ignoran ese mensaje, en algún momento eliminamos el viejo resolutor que dice "te lo advertimos".

¿Hay otros que me he perdido? ¿En particular, en cualquier lugar donde no sea posible desaprobar y luego eliminar la resolución anterior?

Por cierto, ¿cuál es el mejor lugar para publicar escenarios de "aquí hay un caso límite en el que pensé", para que no se pierdan? Creo que sería útil recopilar tantas situaciones extrañas como podamos con anticipación, aunque solo sea para que podamos comenzar temprano a escribir casos de prueba :-)

PD Probablemente también deberíamos, como parte del trabajo de preparación para el nuevo resolver, estudiar cuáles son los problemas de restricción "típicos" (según lo que hay en PyPI). Por mi parte, es bastante raro que tenga algo más complejo que "pip install". Sería una pena enredarse tanto en los casos complejos que perdamos de vista la gran mayoría de los más simples.

1. resolver es demasiado lento (ver conda). Si tengo que elegir entre una resolución de más de 20 minutos o el comportamiento actual, a menudo quiero el comportamiento actual (o al menos intentarlo; en muchos casos dará un resultado que está bien).

2. metadatos incorrectos. no es un gran problema hoy en día, pero es fácil imaginar casos que deberían ser solucionables pero no lo son. Los metadatos de PyPI están en peor estado que los metadatos de conda/conda-forge, y ya es un problema para conda. si está mal y como usuario no puedo obtener una solución, querré obtener alguna opción de exclusión.

@rgommers Para 6, la opción de estilo "ignorar conflictos de versión en este paquete" podría funcionar, ¿verdad?

Gracias, @rgommers , esos son buenos puntos.

El solucionador es demasiado lento, contaría como un error de resolución. Si no puede dar resultados suficientemente eficaces en casos simples, en mi opinión, eso no es adecuado para su propósito. Si, por otro lado, tiene una red de restricciones masivamente compleja que lleva más tiempo con un resolutor completo (espero que 20 minutos sea una exageración, ¡no lo considero aceptable bajo ninguna circunstancia!), entonces nos estamos metiendo en "cosas que considerar demasiado complejo para soportar" territorio. Dicho de otra manera, ¿alguien ha intentado pedirle a conda que proporcione una resolución "rápida y sucia" inexacta pero rápida? Si no harán eso (y estoy bastante seguro de que no lo harán), ¿por qué es razonable esperar que pip lo haga?

Los metadatos incorrectos son definitivamente algo que consideraría como "no admitiríamos eso" (¡recuerde, estoy hablando de "después de un período de desaprobación" aquí!). En mi opinión, dar a los usuarios tiempo para corregir los metadatos y proporcionar una opción de cláusula de escape "ignorar conflictos de versión en el paquete X" es suficiente, no se debe esperar que conservemos toda la maquinaria antigua solo porque algunas personas no arreglarán sus metadatos.

Pero sí, publicitar el hecho de que necesitamos buenos metadatos porque un sistema de resolución preciso sigue la regla de "basura que entra, basura que sale", y monitorear cómo las personas responden a ese mensaje, es una parte muy importante del proceso de implementación.

Le pido que resuelva mis dependencias después de haber instalado algunos paquetes muy predeterminados de una timonera local.

@jriddy La estrategia de resolución de "usar la instalación existente si es compatible" funcionará para esto.

¿Cuál es el mejor lugar para publicar escenarios de "aquí hay un caso extremo en el que pensé", para que no se pierdan?

https://github.com/pradyunsg/zazo/

Para 6, la opción de estilo "ignorar conflictos de versión en este paquete" podría funcionar, ¿verdad?

sí, eso suena como la opción correcta

(Espero que 20 minutos sea una exageración, ¡no lo considero aceptable bajo ninguna circunstancia!), entonces estamos entrando en el territorio de "cosas que consideramos demasiado complejas para soportar". Dicho de otra manera, ¿alguien ha intentado pedirle a conda que proporcione una resolución "rápida y sucia" inexacta pero rápida? Si no harán eso (y estoy bastante seguro de que no lo harán), ¿por qué es razonable esperar que pip lo haga?

Hay muchas personas que se quejan del rendimiento de conda y están escuchando, pero es mucho trabajo, vea sus publicaciones de blog recientes. No sé si habrá una opción de conda rápida y sucia. Sin embargo, hay soluciones relacionadas (hacks) como conda-metachannel que le permite podar el gráfico de dependencia (incluir/excluir paquetes manualmente) para obtener una solución más rápido. Así que creo que está en la misma línea.

Sin embargo, tenga en cuenta que esto _definitivamente_ será necesario a menos que usted:

• hacer un trabajo mucho mejor que conda de inmediato (no es muy probable, no es que esos tipos no sepan lo que están haciendo, es solo un problema realmente peludo).
• solo tiene problemas más pequeños para resolver (esperemos que no sea cierto, PyPI es grande y con buenos metadatos, los problemas deberían ser grandes)

Los metadatos incorrectos son definitivamente algo que consideraría como "no apoyaríamos eso"

Lo suficientemente justo. Sin embargo, toda la postura sobre "no hacemos cumplir los metadatos correctos" no está ayudando aquí. ¿A menos que eso haya cambiado recientemente? (y lo sé, es algo de PyPI, no de pip, pero está relacionado).

No estoy seguro de que realmente tengas las opciones que crees que tienes.

¿En qué se diferencia un resolutor rápido y sucio de uno preciso? ¿Qué suelta para ser más rápido? Las restricciones son restricciones, no vienen en grados. O los satisfaces o no. Quizás pueda satisfacerlos solo por nombre para comenzar, luego por versión, etc.

Cuando las personas están molestas porque Conda es lento, básicamente siempre se debe a metadatos incorrectos. Tenga en cuenta que se le culpará por cualquier lentitud percibida, independientemente de la causa raíz. Los metadatos incorrectos a veces son una restricción incorrecta, pero más a menudo es la falta de una restricción lo que permite considerar una opción mucho más antigua e indeseable. Conda mejoró enormemente recientemente al hacer una pequeña cosa: eliminar nuestra colección anterior de software que tenía restricciones inadecuadas (en su mayoría demasiado abiertas). Estas restricciones abiertas hicieron que conda explorara soluciones realmente malas que requerían muchas degradaciones. Aquí es donde resolver tomó literalmente horas. Las degradaciones son operaciones muy, muy costosas debido a la forma en que pueden funcionar en cascada, y cada paso se vuelve menos restringido y más costoso.

El problema con la mentalidad de "entra basura, sale basura" es que, como mantenedores del solucionador, usted tiene la bolsa. A menos que tenga muy buenas heurísticas para lo que es basura, es impotente. Usted termina siendo el que tiene que investigar por qué el solucionador es lento, aislar el paquete problemático y luego pedirle a la fuente del problema que solucione las cosas. No es una gran posición para estar, confía en mí. Pasamos un montón de tiempo tratando de explicarle a la gente por qué conda tarda una eternidad o no funciona con una combinación de conda-forge, bioconda u otros canales de terceros. Terminamos teniendo que hacer el trabajo de detective y decirles a esos canales de terceros lo que necesitan arreglar. apesta

Cualquier comparación con conda necesita considerar que conda está tomando un enfoque muy diferente al problema. Conda tiene una fuente gigante de metadatos y resuelve todo a la vez, pero pip está resolviendo y optimizando recursivamente cada cosa a la vez (retrocediendo según sea necesario). Eso puede permitirle diferentes rutas de optimización.

@wolfv exploró recientemente el uso de libsolv para conda. En última instancia, se sintió frustrado porque no pudo lograr que diera las mismas respuestas que conda. Todo se reduce a esta diferencia entre los enfoques. Libsolv es un solucionador de retroceso. Puede servir como un complemento compilado opcional para pip para acelerar las cosas, aunque sé que eres sensible a no incluir el código compilado directamente con pip.

( @pradyunsg acaba de publicar su actualización de agosto en su blog ).

Algunas de las preguntas y necesidades que la gente plantea ahora son cosas que debemos comenzar a recopilar ahora, como casos de prueba.

Pero también: ¿qué cronograma creemos que es realista para este lanzamiento? Esto depende mucho de la salud y el tiempo libre de Pradyun, y la disponibilidad de revisión de código de otros mantenedores de pip, y si obtenemos algunas subvenciones que estamos solicitando, pero creo que la secuencia es algo así como:

• refactor de lógica de compilación: en progreso, hecho en algún momento de diciembre a febrero
• Investigación y diseño de UX, construcción de infraestructura de prueba, hablar con usuarios y usuarios intermedios sobre banderas de configuración y cronogramas de transición: necesitamos fondos para esto; el comienzo más temprano es probablemente diciembre, tomará 2-3 meses
• introduzca las abstracciones definidas en resolvelib/zazo mientras realiza las pruebas alfa: llevará algunos meses, por lo tanto, con una estimación conservadora, ¿mayo de 2020?
• adoptar una mejor resolución de dependencia y realizar pruebas beta: ?

¿Es esto correcto? ¿Qué me estoy perdiendo?

Pregunto porque, en mi opinión, parte del trabajo de recopilación de información es algo que un administrador de proyectos y/o investigador de UX debería hacer, y porque algunos avances en https://github.com/pypa/packaging-problems/issues/264 y otros problemas pueden ayudar con las preocupaciones que la gente ha planteado aquí.

Los metadatos incorrectos a veces son una restricción incorrecta, pero más a menudo es la falta de una restricción lo que permite considerar una opción mucho más antigua e indeseable.

Dado que el uso de dependencias sin restricciones o >= some_old_version es la regla y no la excepción para setup.py / pyproject.toml , esto será un problema. Realmente no me importa si se trata de una "restricción incorrecta" o si el solucionador necesita tomar decisiones diferentes: este es el estado de los metadatos en PyPI.

Estas restricciones abiertas hicieron que conda explorara soluciones realmente malas que requerían muchas degradaciones.

Usted es el experto aquí, pero ¿no hay soluciones pragmáticas para esto? En la mayoría de los casos, no se necesitan degradaciones, así que intente solo eso primero. Luego, baje de categoría solo 1 versión para cada paquete. Si necesita degradar aún más, casi siempre es la solución incorrecta (puede deberse a metadatos incorrectos o algo más).

En realidad, no estoy seguro de si pip _puede_ incluso rebajar las cosas. Primero tenía una estrategia demasiado agresiva de "actualizar todo", ahora "actualizar según sea necesario" funciona bastante bien. Nunca lo he visto degradar nada y, en la práctica, funciona bastante bien para un uso regular.

Un ejemplo de degradación con el que conda debe lidiar, pero pip no: los usuarios de anaconda o miniconda con python 3 comienzan con python 3.7. Los usuarios a veces necesitan instalar algo que solo está disponible para Python 3.6. El solucionador debe degradar python y todos los demás paquetes que no sean de noarch. Este es un caso especial que quizás podría optimizarse al tener un comportamiento especial para los cambios de versión de Python, pero ilustra el punto de cómo los cambios en un paquete pueden requerir cambios a otro. "Ha funcionado hasta ahora" es pura suerte, no lo que realmente funciona todo el tiempo.

En cuanto a la restricción de versiones, no puede aplicar eso en la resolución en sí. Tiene sus limitaciones, y cualquier tipo de "apertura por una versión" no puede esperar ser lo suficientemente general, porque es diferente para cada paquete. Sin embargo, puede cortar los metadatos por versión anterior al solucionador. Eso es lo que es "current_repodata.json" de conda. Solo la última versión. Hace que las cosas vayan muy rápido cuando funciona, pero la gente se enojaría mucho si esos fueran los únicos informes. Las cosas no serían reproducibles y se sentirían frustrados porque las especificaciones que funcionan un día pueden no funcionar al día siguiente. Proporcionamos una alternativa a los repodatos completos y también planeamos introducir subconjuntos basados ​​en el tiempo, con solo las versiones más recientes disponibles en determinados momentos. La apertura incremental de los datos de índice disponibles podría ser un concepto más útil con el solucionador de retroceso.

pip _puede_ incluso degradar cosas.

Puede: para pip, la degradación es solo un paso de desinstalación e instalación como la actualización. Y baja de categoría cuando ve una restricción que se le ha pedido que satisfaga.

Lo siguiente degrada las herramientas de configuración, siempre que sea lo primero que vea pip:

pip install "setuptools < 20.0"

¿Cuál es el mejor lugar para publicar escenarios de "aquí hay un caso extremo en el que pensé", para que no se pierdan?

https://github.com/pradyunsg/zazo/

Gracias, lo tendré en cuenta. Aunque al repensar, mi "caso patológico" en realidad no es tan patológico. En su mayoría, es solo un caso extremo del hecho de que para conocer los metadatos de dependencia de un paquete, debe descargar y descomprimir el paquete y, en ciertos casos, esto puede desencadenar la descarga de muchos paquetes solo para rechazarlos. Esa podría ser una limitación importante del protocolo de "índice simple" que debemos abordar, pero no es directamente un problema de resolución.

Un ejemplo de degradación con el que conda debe lidiar, pero pip no: los usuarios de anaconda o miniconda con python 3 comienzan con python 3.7. Los usuarios a veces necesitan instalar algo que solo está disponible para Python 3.6. El solucionador debe degradar python y todos los demás paquetes que no sean de noarch. Este es un caso especial que quizás podría optimizarse al tener un comportamiento especial para los cambios de versión de Python, pero ilustra el punto de cómo los cambios en un paquete pueden requerir cambios a otro. "Ha funcionado hasta ahora" es pura suerte, no lo que realmente funciona todo el tiempo.

También es un caso en el que normalmente _no quieres bajar de categoría_. Como usuario, prefiero obtener una excepción que me diga que el paquete no está disponible y que me permita instalar explícitamente 3.6 si eso es lo que quiero.

Otro ejemplo es la inconsistencia entre canales. Ejemplo reciente: estábamos en Python 3.7.3, luego base obtuvo 3.7.4 . No me importan esas diferencias de versión, y la mayoría de los usuarios no lo harán. Un "no hacer nada" predeterminado sería mucho mejor que "hey .4 > .3 , actualicemos eso y luego cambiemos los canales de otros paquetes a base si es necesario (incluso si eso los degrada)".

Brindamos una alternativa a los repodatos completos y también planeamos introducir subconjuntos basados ​​en el tiempo, con solo las versiones más recientes disponibles en determinados momentos.

Eso suena como una mejora muy útil.

El problema con la mentalidad de "entra basura, sale basura" es que, como mantenedores del solucionador, usted tiene la bolsa. A menos que tenga muy buenas heurísticas para lo que es basura, es impotente.

Si eso es verdad. Creo que cada IDE, distribución o "interfaz común para un montón de cosas" tiene este problema.

Lo siguiente degrada setuptools

Esa es una degradación solicitada por el usuario. Una indirecta es lo que quise decir (por ejemplo setuptools<20.0 en pyproject.toml`). Eso también funcionaría, supongo, pero es raro en la práctica.

El problema con la mentalidad de "entra basura, sale basura" es que, como mantenedores del solucionador, usted tiene la bolsa.

100% de acuerdo. Es algo que hay que manejar con mucho cuidado. Pero a la inversa, tratar de encontrar un comportamiento sensato para cualquier chatarra vieja no es viable: tenemos que trazar una línea en alguna parte .

Solo como recordatorio, esta discusión se desencadenó por la pregunta de si necesitaríamos retener el solucionador existente indefinidamente. No estoy seguro de que ninguno de estos puntos realmente afecte esa pregunta: el solucionador existente no es correcto, lo mejor que puede decir es que es un comportamiento roto con el que la gente está familiarizada. Por lo tanto, mantengo lo que dije anteriormente, no hay motivo para conservar el sistema de resolución anterior más allá de un período de transición inicial.

Y, de hecho, para una gran parte de los casos de uso, los resolutores antiguos y nuevos probablemente darán los mismos resultados de todos modos.

"Correcto" no les importa a los usuarios cuando se rompen por sus cambios. Cualquier cambio en el comportamiento enfurecerá absolutamente a algunos usuarios. Decirles que su flujo de trabajo es incorrecto y que necesitan cambiar no ha sido una estrategia terriblemente efectiva para mí. Creo que necesitas tocarlo de oído. Ciertamente, no me gustaría mantener el sistema de resolución anterior para siempre, pero probablemente deba brindarle a las personas un camino para mantenerlo, como convertirlo en un complemento que otra persona adopte y mantenga, y las personas pueden instalarlo por separado de pip.

tratar de encontrar un comportamiento sensato para cualquier chatarra vieja no es viable: tenemos que trazar una línea en alguna parte.

Sí, pero ¿qué es "basura vieja"? ¿Qué lo distingue? ¿Qué pasa con la chatarra mala frente a la chatarra buena (teniendo en cuenta que lo nuevo no siempre es mejor)? Mi consejo es pasar mucho tiempo haciendo que el solucionador sea muy depurable. Facilite a los usuarios (no solo a usted como experto) rastrear dónde van las cosas para que sea fácil identificar cuándo el problema son los metadatos incorrectos y cuáles son esos metadatos incorrectos. Esta es una habilidad que la mayoría de los usuarios actualmente no tienen y, sinceramente, la mayoría de los usuarios que he visto no quieren tener esta habilidad. No creo que usted (o Conda para el caso) alguna vez pueda tener una heurística automática completamente precisa para lo malo contra lo bueno.

También es un caso en el que normalmente no desea degradar. Como usuario, prefiero obtener una excepción que me diga que el paquete no está disponible y que me permita instalar explícitamente 3.6 si eso es lo que quiero.

@rgommers , conda 4.7 se movió a esto, lo que requiere la especificación explícita de python para cambiar las versiones menores. La gente lo ha odiado. No tengo idea de qué fracción de la población son los vocalistas, pero a mucha gente realmente, realmente no le gusta que solían poder conda install algo, y ahora no pueden. No les importa mucho la razón, y en su mayoría se calman con la respuesta, pero mientras tanto, aún tenemos que lidiar con la hostilidad. Solo otro ejemplo de

"Correcto" no les importa a los usuarios cuando se rompen por sus cambios.

Otro ejemplo es la inconsistencia entre canales. Ejemplo reciente: estábamos en Python 3.7.3, luego la base obtuvo 3.7.4. No me importan esas diferencias de versión, y la mayoría de los usuarios no lo harán. Un "no hacer nada" predeterminado sería mucho mejor que "oye, .4 > .3, actualicemos eso y luego cambiemos los canales de otros paquetes a la base si es necesario (incluso si eso los degrada)".

Este es un punto mucho más complicado. Básicamente estás proponiendo diferentes criterios de optimización. Es posible que haya visto los 11 pasos actuales en nuestra publicación de blog en https://www.anaconda.com/understanding-and-improving-condas-performance/

Estos son extremadamente complicados y no existe un óptimo global que satisfaga todas las situaciones. Dada la compatibilidad binaria y los canales como islas de dicha compatibilidad, la fuerte prioridad de los canales es bastante esencial. Las compilaciones de Python no importan, tiene razón, pero actualmente no hay forma de expresar una restricción de compatibilidad binaria frente a una restricción de versión simple y simple. Necesitarías eso para pensar en tu idea de dejar las cosas en paz. De lo contrario, rápidamente estarías en el infierno de la incompatibilidad binaria.

Hola, gracias @msarahan por mencionarme en este número. Quería intervenir antes, pero no he encontrado el momento.

De hecho, experimenté bastante con el uso libsolv como solucionador de especificaciones de conda. Y funciona : la diferencia restante ahora es que a conda no le importa mucho el número de compilación, pero libsolv en la forma en que está codificado (y con el solucionador de retroceso) sí lo hace. Incluso cuando se usa el repodata completo, libsolv es realmente rápido. Me atrevería a decir que la velocidad de libsolv es lo suficientemente rápida como para no ser molesto :)

Mi gran contribución a libsolv fue hacerlo compatible entre plataformas para que ahora se compile en Windows, OS X y Linux.

Recomendaría totalmente usar libsolv para un nuevo resolutor, aunque es una gota de código compilado (al menos es rápido) y @mlschroe podría estar disponible para ayudar; ayudó mucho con el soporte de libsolv para la conda matchspec.

Por otro lado, no estoy seguro de en qué etapa se encuentra el desarrollo del resolutor y si ya es demasiado tarde, y si el código compilado es aceptable o no.

Es posible que haya visto los 11 pasos actuales en nuestra publicación de blog en https://www.anaconda.com/understanding-and-improving-condas-performance/

De hecho lo hice. Esa fue una buena entrada de blog.

Básicamente estás proponiendo diferentes criterios de optimización.

realmente no. Creo que su _"restricción de compatibilidad binaria frente a una restricción de versión simple y simple"_ solo apunta a algo que probablemente me estoy perdiendo. Lo que esperaría es que ningún paquete debería tener python >= 3.7.4 o == 3.7.4 en sus metadatos, siempre es == 3.7 (recién verificado para scipy, meta.yaml dice python y conda_forge.yml dice max_py_ver: '37' - tiene sentido). Por lo tanto, introducir un 3.7.4 no debería hacer nada: el resolutor que elige 3.7.3 y no cambia nada más es mucho más económico (y válido de acuerdo con sus 11 pasos) que forzar 3.7.4 y activar un cadena de subidas/bajadas de grados.

Supongo que esta parte se está desviando del tema para los planes de implementación de pip , así que feliz de llevar esto a otro lugar.

Mi consejo es pasar mucho tiempo haciendo que el solucionador sea muy depurable.

+1

Además: hazlo (mantenlo) lo más reparable posible. Eso es lo bueno con pip ahora, si se estropea, por lo general uno puede hacer cd site-packages && rm -rf troublesome_package (posiblemente seguido de reinstalar con --no-deps ) y todo vuelve a funcionar. Los gustos de conda , apt y amigos son mucho más difíciles de reparar de esa manera.

Básicamente estás proponiendo diferentes criterios de optimización.

No creo que estés teniendo en cuenta el concepto de canales lo suficiente en tu forma de pensar. No sé qué tan relevante es pip. Definitivamente mucho menos de lo que es a conda, pero no estoy seguro si es totalmente irrelevante. Las personas aún pueden recopilar paquetes de más de un índice a la vez, ¿verdad?

Los paquetes no tienen python >=3.7.4, ni ==3.7.4. El estándar en el empaquetado conda es tener un límite superior e inferior. Generalmente, estos son determinados automáticamente por conda-build utilizando la información proporcionada por el autor de la receta con respecto a cuántos lugares de la versión considerar un rango compatible. Los paquetes tienen restricciones como >=3.7.2,<3.8.0a0, con la incomodidad de 0a0 para dar cuenta del hecho de que las versiones preliminares están por debajo de las versiones .0 y, por lo tanto, coincidirían con una especificación <3.8.0 donde las personas no realmente espero que lo haga.

Los paquetes también tienen un canal asociado a ellos. Este canal es efectivamente parte de la optimización de la versión: https://github.com/conda/conda/blob/4.6.7/conda/resolve.py#L1074 : el canal es como una superversión, un lugar por delante del versión principal del paquete. Si una solución no debe cambiar python, entonces la especificación de python no puede ser python == 3.7; ese es un rango, y el canal afectará ese rango. Específicamente, tener una especificación python ==3.7 y comenzar con una instalación desde el canal defaults , luego agregar el canal conda-forge resultará en una gran rotación, porque ha introducido nuevos paquetes de python que son más altos en "versión" (incluido el canal), y su especificación de python permite ese cambio.

Conda 4.7 introdujo un "congelamiento" de especificaciones mucho más agresivo, y estoy bastante seguro de que ese comportamiento es lo que buscas. Sin embargo, eso es bastante complicado. Se reduce a solo congelar cosas que no entren en conflicto con sus especificaciones explícitas. Cómo determinas el "conflicto" es la parte difícil. Creemos que es mejor no congelar cosas que impidan que el solucionador proporcione al usuario los paquetes más nuevos que forman parte del gráfico de dependencias de ese paquete. Vale la pena mencionar esta congelación porque se puede hacer según las especificaciones para pip de una manera que no se puede hacer conda. Creo que podría ser una gran optimización para un solucionador de retroceso.

Además: hazlo (mantenlo) lo más reparable posible. Eso es lo bueno con pip ahora, si se estropea, por lo general uno puede hacer cd site-packages && rm -rf problemsome_package (posiblemente seguido de reinstalar con --no-deps) y todo vuelve a funcionar. Los gustos de conda, apt y amigos son mucho más difíciles de reparar de esa manera.

Sí, esto es muy importante. Creo que pip ha hecho un buen trabajo al vender las cosas de manera juiciosa para que sea más difícil de romper. Eso es muy sabio, y Conda está aprendiendo de eso. Si termina usando cualquier código compilado, asegúrese de que esté vinculado estáticamente o que sea imposible que la carga dinámica cause problemas.

(tangente de libsolv: cuando solía trabajar para RH, agarré https://pypi.org/project/solv/ para cerrar la brecha de seguridad "pip install solv" en Fedora, ya que el proceso de compilación de libsolv no genera un sdist o archivo de rueda en este momento, y mucho menos publicarlo en PyPI. Feliz de chatear con cualquier persona que pueda estar interesada en hacer esos enlaces de biblioteca reales con una copia de paquete de libsolv, en lugar del inocuo marcador de posición que es ahora)

Con respecto a mi comentario de "optar por no participar", no me refiero a "volver a la lógica de instalación anterior", me refiero a "proporcionar una opción para omitir la instalación de paquetes que causarían violaciones de restricciones, en lugar de fallar en la solicitud de instalación completa".

Yum/DNF ofrecen eso a través de su opción --skip-broken (en DNF esa bandera es un alias para --setopt=strict=0 ), y creo que el resolutor pip debería ofrecer una opción similar.

@ncoghlan Ah, cierto. Eso tiene sentido.

Opción de estilo "ignorar conflictos de versión en este paquete"

Ya mencioné que haríamos eso, por eso me confundió tu comentario.

Estamos en la misma página entonces. :)

@ncoghlan respondió a mi cronograma propuesto en distutils-sig y dijo que suena razonable.

@pradyunsg : ¡esperando su próxima actualización mensual!

Pasé un tiempo echándole un vistazo a esto nuevamente y archivé #7317.

Creo que casi llegamos a las abstracciones, gracias a mucho trabajo en la interacción del índice de pip, la resolución de dependencias + la separación lógica de compilación y un montón de limpieza general.

Acabo de cerrar #7317. Por lo que puedo decir, la resolución de dependencia ahora está desacoplada (lo suficiente) de la lógica de compilación de metadatos. El refactor de lógica de compilación ha progresado bien y ahora ya no es un obstáculo para seguir avanzando.

Ahora podemos comenzar a trabajar en la implementación de las abstracciones [resolvelib] en pip, tomando referencias de [passa] y del resolvedor de poesía cuando corresponda. :)

@pradyunsg Estoy planeando extraer el resolver base (basado en PubGrub) del código base de Poetry (ver https://github.com/sdispater/poetry/tree/master/poetry/mixology). Está mayormente desacoplado del resto del código, pero todavía hay referencias a partes internas que necesito abstraer.

Si está interesado en ayudar con eso, por favor hágamelo saber. La idea es tener una implementación independiente del algoritmo PubGrub que puedan usar terceros y se colocará en https://pypi.org/project/mixology/ que actualmente contiene el código del antiguo solucionador.

@sdispater ¡Definitivamente! No sé si puedo ayudar directamente (limitaciones de tiempo), ¡pero sería genial si pudieras desvincular el puerto PubGrub del resto de la poesía!

Una de las cosas que sería realmente agradable sería tener una capa de abstracción consistente, de modo que pip, poet y pipenv usen las mismas abstracciones. En este momento, tenemos zazo (mío), mixología (poesía) y resolvelib (pipenv): todos definen una capa de abstracción de algún tipo y son ligeramente diferentes pero (¡ridículamente!) similares. Si estás abierto a esto, ¡háznoslo saber!

Para tu información, nosotros ( @wolfv y el equipo de @QuantStack en general) hemos respondido a la RfP para la resolución de dependencias de pip.

El enfoque propuesto es adoptar la biblioteca libsolv C y contribuir con el soporte para el formato de restricciones de versión de pip a libsolv. Expondríamos la biblioteca C a través de nuevos enlaces de Python.

Libsolv es una biblioteca reforzada en batalla que subyace al ecosistema RPM y, por lo tanto, ya se usa a escala industrial.

• Libsolv se distribuye bajo la licencia BSD-3-Clause.
• Libsolv admite múltiples paquetes y formatos de repositorio, como rpm , deb ,
  haiku , conda , arch . Es importante destacar que la variedad de formatos y formas de expresar
  restricciones de dependencia muestra que es un sistema conectable que debería poder
  para acomodar la sintaxis de pip para las restricciones en las versiones de dependencia.
• Usando libsolv en lugar del solucionador de conda en el envoltorio delgado de mamba, estábamos
  capaz de mejorar significativamente las actuaciones de conda. (la lentitud de conda en la resolución de paquetes con canales grandes fue nuestra principal motivación para trabajar en mamba).
• Funciona multiplataforma en Windows, OS X y Linux. ( @wolfv hizo el puerto de Windows de libsolv)
• Realiza una resolución completa de SAT para encontrar combinaciones de dependencia óptimas y, si no tiene éxito, devuelve sugerencias procesables para la resolución de conflictos.

El enfoque propuesto es adoptar la biblioteca libsolv C

Tendría que haber un respaldo para las plataformas que libsolv no admite (por ejemplo, se está trabajando activamente en el soporte de AIX en pip, y no mencionó BSD). Entonces, libsolv como una opción de rendimiento donde esté disponible es plausible para mí, pero en realidad no estamos en condiciones de usarlo solo . (¿Existe una versión Python pura de libsolve, es decir, algo que dé los mismos resultados, solo que más lento?)

Además, ¿cómo funcionaría get-pip.py? ¿Tendríamos que incluir binarios para libsolv para todas las plataformas posibles? Nuevamente, supongo que no, usaríamos un respaldo de Python puro.

No poder usar código C externo ha sido una molestia para pip durante mucho tiempo. Me gustaría ver una buena solución para esto, pero (a) no estoy seguro de que haya una (salvo alguna forma de solución de arranque "mini-pip" que nos permita eliminar el proveedor por completo) y (b) es un trabajo tan grande que odiaría que el nuevo resolutor dependiera de él.

Hola @pfmoore

Creo que el soporte de plataforma adicional no debería ser tan difícil de lograr, ya que libsolv es un código C bastante sencillo. Sin embargo, estoy bastante seguro de que no existe una versión Python pura de libsolv (lo que entiendo es un inconveniente, pero tampoco hay una versión Python pura de Python, o la biblioteca estándar de Python, por lo que, en mi opinión, no debería ser un bloqueador).

Creo que para el arranque, uno podría tener un pip de Python puro que usa el mecanismo actual para resolver, que luego instala la biblioteca de resolución necesaria basada en libsolv. Por ejemplo, uno podría anclar el paquete exacto de enlaces de Python específicos de libsolv + pip e instalarlos desde boostrap-pip como usted describe. Suena totalmente factible para mí, pero es posible que sepas mejor lo que estaría involucrado...

Creo que el soporte de plataforma adicional no debería ser tan difícil de lograr

Para ser claros, no tengo un interés personal en las plataformas más especializadas, solo creo que debemos ser muy claros si estamos impactando en qué plataformas se admite pip (que en este momento es básicamente "cualquier cosa que pueda ejecutar Python" ). También está la pregunta de implementación de cómo enviamos una extensión C (ya que pip se envía actualmente como una rueda "universal", y eso es importante para algunos casos de uso como get-pip.py )

Creo que para el arranque, uno podría tener un pip de Python puro que use el mecanismo actual para resolver

He argumentado anteriormente, y lo repetiré aquí, realmente no quiero tener que mantener dos resolutores en pip indefinidamente.

Pero no quiero ser demasiado negativo sobre la propuesta, solo quería señalar algunas de las razones por las que actualmente no permitimos dependencias en extensiones C, en caso de que no las conozca.

La discusión probablemente sea más adecuada en otro lugar, y podría ser totalmente redundante cuando/si se revelan más detalles, pero realmente quiero dejar salir mis preguntas ahora.

Según tengo entendido, libsolv usa un solucionador completamente SAT para la resolución de dependencias y requiere cargar primero la información de dependencia antes de que comience a resolverse. Pero PyPI a partir de ahora almacena metadatos de dependencia por paquete. Incluso si ignora la naturaleza dependiente del tiempo de ejecución de setup.py , sería difícil obtener de manera eficiente la información necesaria para el solucionador SAT.

¿Cómo planea manejar este problema? ¿Planea implementar infraestructura (y propone especificaciones adicionales para implementaciones de repositorios de terceros) para generar archivos .solv cuando se cargan los paquetes? ¿O tiene algunas estrategias bajo la manga para generar datos solucionables apropiados a medida que avanza el solucionador, y tal vez implementar un retroceso a medida que ingresan nuevos datos de dependencia?

No estoy al tanto de ningún trabajo existente en este sentido, y la mayoría de los recursos que puedo encontrar sugieren que el panorama de empaquetado de Python necesita algo más que un solucionador de SAT directo. Así que estoy muy interesado en cualquier posibilidad aquí.

Esos archivos .solv son solo para almacenamiento en caché, libsolv no los necesita para resolverlos. Pero estoy de acuerdo en que la naturaleza dinámica de las dependencias de PyPI dificulta el uso de un solucionador SAT.

(Consulte https://docs.google.com/document/d/1x_VrNtXCup75qA3glDd2fQOB2TakldwjKZ6pXaAjAfg/edit para obtener más información)

(Tenga en cuenta que un solucionador SAT es solo un solucionador de retroceso que también aprende cláusulas si se encuentra con un conflicto, por lo que creo que es posible usar un solucionador SAT para PyPI. Pero debe ser un solucionador que permita agregar cláusulas dinámicamente mientras resuelve).

Los solucionadores de satélites tienen algunas capacidades significativas en estos días, incluidas adiciones dinámicas, reinicios, retrocesos, reinicios aleatorios, etc. Pero creo que los desafíos aquí serán en parte técnicos relacionados con la necesidad de admitir plataformas donde no hay garantía de que pueda construir un solucionador basado en C.

Estoy en el aeropuerto en este momento, así que no puedo responder a los puntos que se han planteado en este momento , pero... Estoy seguro de que no deberíamos estar discutiendo las opciones/compensaciones técnicas aquí. cómo nos comunicamos y gestionamos la implementación frente a lo que implementamos. :)

Presenté el n.° 7406 para una mayor discusión sobre las compensaciones técnicas: @sdispater , @techalchemy , @uranusjr , @wolfv Agradecería que pudiéramos tener una discusión adicional sobre las diversas opciones para el diseño del resolutor.

Para establecer expectativas temprano, viajaré durante las próximas 2 semanas y espero poder ponerme al día con toda la discusión el ~ 9 de diciembre.

Actualización de estado: el PSF pudo obtener algunos fondos del Soporte de código abierto de Mozilla y la Iniciativa Chan Zuckerberg para contratar contratistas para trabajar en la resolución de pip y problemas relacionados con la experiencia del usuario . Puede ver nuestra hoja de ruta (que necesito pulir) y blogs, foros y listas de correo y notas de reuniones recientes para mantenerse informado. Pronto publicaré algo sobre esto en distutils-sig y en el foro de Empaquetado en la instancia Discourse de Python .

Nuestro objetivo es tener la función de resolución de pip preparada para su lanzamiento en pip 20.2 en julio. (Según la cadencia de lanzamiento trimestral de pip, las dificultades imprevistas pueden retrasarse hasta el 20,3 en el próximo trimestre).

@uranusjr :

Según tengo entendido, libsolv usa un solucionador completamente SAT para la resolución de dependencias y requiere cargar primero la información de dependencia antes de que comience a resolverse. Pero PyPI a partir de ahora almacena metadatos de dependencia por paquete. Incluso si ignora la naturaleza dependiente del tiempo de ejecución de setup.py, sería difícil obtener de manera eficiente la información necesaria para el solucionador SAT.

El comando prototipo pip resolve en #7819 usa dos técnicas para obtener esta información de manera eficiente (vea ese problema para más detalles):

1. > Extraer el contenido del archivo METADATA de una URL para una rueda sin descargar la rueda en absoluto.
2. > Almacenamiento en caché del resultado de cada llamada self._resolve_one() en un archivo json persistente.

La técnica utilizada para (1) es capaz de convertir una URL de rueda en una lista de cadenas de requisitos de las que depende muy rápidamente, mientras descarga solo unos pocos KB del contenido de la rueda. El prototipo en #7819 luego asegura que se llame a req.populate_link() en cada uno de los requisitos dependientes devueltos por self._resolve_one() y almacena el mapeo de (==Requirement, url) -> [list of (==Requirement, url) non-transitive dependencies] en un archivo de caché json persistente. (1) obtiene información nueva rápidamente, (2) hace que la información antigua sea rápida de consultar.

Si bien aún no estoy familiarizado con libsolv, creo que las entradas de este mapeo desde la URL requerida hasta las dependencias y sus URL pueden ser exactamente la entrada atómica requerida por un solucionador SAT. Como se demostró en el n.° 7189, el archivo de caché de dependencia de json persistente provocó que las invocaciones de pip resolve se volvieran completamente inoperativas después de la primera ejecución, lo que tomó entre 800 y 900 ms en la línea de comando a partir de ese momento. Si se utilizan las técnicas de (1) y (2), creo que es posible dejar que un solucionador SAT se ejecute hasta el final cada vez que se invoca pip sin esperar un tiempo increíblemente largo. Probablemente no sería demasiado difícil intentar hackear libsolv sobre el prototipo en #7189 para hacer este número más concreto.

@techalchemy :

Los solucionadores de satélites tienen algunas capacidades significativas en estos días, incluidas adiciones dinámicas, reinicios, retrocesos, reinicios aleatorios, etc. Pero creo que los desafíos aquí serán en parte técnicos relacionados con la necesidad de admitir plataformas donde no hay garantía de que pueda construir un solucionador basado en C.

pants solía tener un código que facilitaba la exposición de un compilador y un enlazador a un proyecto basado en setup.py (#6273), pero luego lo eliminamos (ver #7016) a favor de hacer posible construir C/C++ en pantalones sin usar setup.py , que era apropiado para nuestro caso de uso dentro de Twitter, que solo necesitaba crear una biblioteca compartida para los operadores personalizados de TensorFlow . Alojamos archivos binarios preconstruidos para archivos GCC y binutils vinculados estáticamente en nuestro s3 para OSX y Linux (consulte https://github.com/pantsbuild/binaries/) para que los usuarios de pantalones no tengan que instalar nada más que Python y un JDK. usar pantalones en absoluto.

Me interesaría ayudar a generar ideas y/o desarrollar cualquier tipo de herramienta para construir C y C++ de manera portátil que pueda permitir que pip dependa de manera confiable de libsolv en todas las plataformas compatibles.

@cosmicexplorer

pants solía tener un código que hacía más fácil exponer un compilador y un enlazador a un proyecto basado en setup.py (#6273), pero luego lo eliminamos (ver #7016) a favor de hacer posible la compilación de C/C++ en pantalones sin usar setup.py, que era apropiado para nuestro caso de uso dentro de Twitter, que solo necesitaba crear una biblioteca compartida para los operadores personalizados de TensorFlow. Alojamos binarios prediseñados para archivos GCC y binutils vinculados estáticamente en nuestro s3 para OSX y Linux (consulte pantsbuild/binaries) para que los usuarios de pants no tengan que instalar nada además de python y un JDK para usar pants.

¡El trabajo del compilador/enlazador es muy interesante! También hay una discusión sobre cómo desacoplar el compilador de setup.py (o un backend de compilación PEP 517 en general). No está realmente relacionado con el resolver (al menos no directamente), pero podría estar interesado: https://discuss.python.org/t/how-do-we-get-out-of-the-business-of- conducción-c-compiladores/2591

@cosmicexplorer

Me interesaría ayudar a generar ideas y/o desarrollar cualquier tipo de herramienta para construir C y C++ de manera portátil que pueda permitir que pip dependa de manera confiable de libsolv en todas las plataformas compatibles.

@wolfv y yo hemos estado buscando esto para construir partes de la pila del administrador de paquetes DNF en todas las principales plataformas compatibles para mamba y mi propio trabajo personal con DNF. En este momento, libsolv ahora se puede construir para Windows, Linux, macOS, BSD, Haiku OS, y estoy vagamente al tanto de que se está instalando en varios sistemas UNIX como parte del uso de DNF en UNIX. Sé que @dralley también ha puesto a disposición ruedas binarias solv para ~las principales plataformas compatibles con PyPI~ Linux usando manylinux2014 en PyPI .

Ahora tenemos pip 20.1b1, una versión beta que incluye una versión muy temprana (alfa) del nuevo resolver (ver #8099 para el contexto sobre eso, y una encuesta donde las personas pueden dar su opinión). Aquí está el anuncio . Y https://github.com/pypa/pip/issues/7951#issuecomment -617851381 enumera algunos lugares en los que hemos publicado la versión beta hasta ahora.

pip 20.1 ya está disponible e incluye la versión alfa del resolver.

Estamos discutiendo la publicación de otro lanzamiento de pip en mayo, uno que incluye un alfa más avanzado del resolutor. Y estamos averiguando cuándo lanzar la versión beta del nuevo resolutor y hacer un impulso de "prueba esto".

Tuvimos retrasos mientras descubríamos el #8371, cómo mostrar mejor ciertos mensajes de error y cómo manejar un montón de otras cosas peludas; consulte https://github.com/pypa/pip/projects/6 y https://github.com/pypa/pip/projects/5 para obtener más información sobre nuestro progreso. #8206 es una discusión sobre la próxima versión beta, pip 20.2b2, que espero podamos publicar a fines de junio.

He publicado nuestro informe de mitad de año en el blog de PSF . Una cosa clave que debe saber: a finales de este mes lanzaremos pip 20.2 , que tendrá una versión beta del nuevo solucionador de dependencias (pip 20.1 tenía una versión alfa) disponible a través de un indicador opcional " --use-feature=2020-resolver ". Publicitaremos mucho pip 20.2 y pediremos a muchos usuarios que pongan a prueba el nuevo resolutor.

Por #8511 ahora hemos lanzado pip 20.2 . Esta versión incluye la versión beta del solucionador de dependencias de última generación . Es significativamente más estricto y consistente cuando recibe instrucciones incompatibles y reduce la compatibilidad con ciertos tipos de archivos de restricciones, por lo que algunas soluciones y flujos de trabajo pueden fallar. Pruébelo con la --use-feature=2020-resolver . Consulte nuestra guía sobre cómo probar y migrar, y cómo informar problemas . El nuevo solucionador de dependencias está desactivado de forma predeterminada porque aún no está listo para el uso diario .

Planeamos hacer el próximo lanzamiento trimestral de pip, 20.3, en octubre de 2020. Nos estamos preparando para cambiar el comportamiento de resolución de dependencia predeterminado y hacer que el nuevo solucionador sea el predeterminado en pip 20.3.

Haga correr la voz señalando esta publicación de blog : corra la voz en Hacker News, Reddit, Twitter, Facebook, Dev.to, Telegram, respuestas relevantes de Stack Overflow y sus Slacks y Discords favoritos. La mayoría de las personas a las que esto afectará no se mantienen al día con las noticias específicas para desarrolladores de Python. Ayúdelos a obtener información antes de octubre y ayúdenos a obtener sus informes de errores.

(Copiando mi nota del #988.)

@zooba preguntó :

¿Crees que deberíamos actualizar la versión de pip incluida con Python 3.9 en esta etapa (para el primer RC)?

Del mismo modo, ¿es necesario actualizar Python 3.8 para su próxima versión?

Mi suposición es que, sí, después del lanzamiento de la corrección de errores a principios de la próxima semana, sí, pero @pfmoore @xavfernandez @cjerdonek @uranusjr @pradyunsg @dstufft ¿qué piensas?

Lo sentimos, golpeó la publicación demasiado pronto. Mi razonamiento es que agrupar pip 20.2 hará que sea mucho más fácil para los desarrolladores experimentados probar el nuevo solucionador de dependencias fácilmente mientras prueban las versiones más nuevas de Python. Pero no sé cuánto trabajo es actualizar esa versión incluida, o con qué frecuencia desea hacerlo.

Lo mismo aquí, sería bueno incluir un 20.2.x en 3.9 para facilitar el acceso al nuevo resolver.

¿Qué piensas?

Tienes razón, ese es el plan. :)

De acuerdo, respondí en python-dev : sí, la versión de pip incluida en Python 3.8 y 3.9 debe actualizarse a 20.2.x.

Por separado, sobre publicidad, señalaré aquí algunos trabajos en progreso:

Durante las próximas 6 a 8 semanas, presionaré para obtener una amplia publicidad para que los usuarios intenten usar el nuevo pip. Sospecho que el problema no será tanto "este paquete individual no se instalará"; habrá conflictos inesperados entre paquetes particulares, tal vez dependiendo del entorno y los archivos de restricciones particulares. Estamos tratando de obtener algunos comentarios tempranos a través de la encuesta para que podamos corregir errores, configurar más pruebas automatizadas, etc., y para que esos paquetes ascendentes puedan recibir avisos y sacar paquetes reparados antes de pip 20.3 (ejemplo : el problema de TensorFlow/numpy/scipy en https://github.com/pypa/pip/issues/8076#issuecomment-666493069).

No importa cuánto esfuerzo pongamos en esto, habrá usuarios que se enfrenten a inconsistencias que se tropiecen con 20.3, y se sentirán frustrados, confundidos y heridos, y eso causará una carga de soporte para nosotros y para todos sus upstream. Nuestro objetivo es reducir esto haciendo que los usuarios prueben y atrayendo la atención de los usuarios.

Así que planeo contactar y aprovechar los grupos que prestan atención a sus propios rincones específicos de dominio : los científicos de datos, los maestros, los artistas, los especialistas en DevOps, etc.

Tengo la hipótesis de que una forma de llamar su atención es a través de los paquetes específicos en los que confían.

Ayer revisé algunas listas de paquetes ampliamente utilizados y envié correos electrónicos manualmente a algunas personas y creé problemas en algunos repositorios para sugerir que pidieran a sus usuarios que probaran con la versión beta del nuevo solucionador, para comenzar a rodar y probar algunos redacción/enfoques para obtener más publicidad y pruebas. Esto generó confusión en al menos un caso (consulte https://github.com/sqlalchemy/mako/issues/322#issuecomment-667546739) y una vez que se publique la corrección de errores de 20.2, seré un poco más sistemática y más clara sobre

• por qué nos estamos acercando
• a quién hemos elegido contactar/cuándo (la vinculación a una estrategia de medios públicos ayudará)
• por qué no podemos usar pruebas automatizadas para encontrar estos problemas nosotros mismos

Hemos recibido un poco de atención en Twitter ( 1 , 2 ) y Reddit (¿alguien quiere responder a esta pregunta sobre la financiación de PyPA ?).

@zooba escribió (con respecto a la agrupación):

Gracias. Parece que podemos hacerlo más adelante esta semana y hacer la próxima ronda de lanzamientos. Háganos saber lo antes posible si surge algo que no desea que se publique.

Creo que --use-feature=2020-resolver para mí generalmente soluciona más problemas de los que causa.

¿Es demasiado tarde para sugerir una implementación inicial a través de:

pseudocódigo 20.3 propuesto

try:
    _2020_resolver()
except:
    legacy_resolver()

lo que significaría que al menos para mis proyectos todos pasarían sin modificación

Después de eso, una vez que el resolutor heredado esté deshabilitado de forma predeterminada, es posible que durante un tiempo tenga algunos proyectos que funcionen con el resolutor 2020 y otros que no funcionen con el resolutor heredado. Me gustaría poder establecer un indicador para habilitar un respaldo:

pseudocódigo 20.4 propuesto

try:
    _2020_resolver()
except:
    if not use_legacy_resolver:
        raise
    legacy_resolver()

Estamos planeando implementar 20.3 a finales de este mes. Anticipamos que esto requerirá un montón de apoyo de los usuarios, ya que los usuarios confundidos nos hacen preguntas.

@di se ha ofrecido como voluntario para ayudar a reunir algunos voluntarios para ayudar con la primera respuesta. Estos voluntarios responderán preguntas y ayudarán con la carga de soporte del usuario una vez que salga el nuevo pip (en Twitter, StackOverflow y GitHub) y escalarán los errores reales a la atención del equipo de mantenimiento/contribuyente.

Dustin, creo que tienes un plan aproximado sobre cómo funcionaría esto. ¿Te importaría publicarlo aquí y luego obtendré un consenso de otros mantenedores de pip? Gracias profundamente.

Aquí está mi plan aproximado:

• Inicie una discusión en debate.python.org solicitando apoyo
• Dirija a la gente a un canal de Slack que podría servir como un canal de comunicación entre todos.
• Comience un documento que describa algunas preguntas frecuentes y nuestras respuestas.
• Incluya un árbol de decisiones para el problema nuevo -> problema clasificado
• Comparta esto con el canal una vez que tengamos una fecha de lanzamiento conocida.
• Intente y programe aproximadamente a los voluntarios para que estén en línea y realicen la clasificación en los días posteriores al lanzamiento.

Gracias, @di. Estamos esperando hasta mañana para obtener la aprobación de otros mantenedores. Y nuestro objetivo es lanzar pip 20.3 el miércoles o jueves, 28 o 29 de octubre.

@di Veo que tu plan está aprobado. ¡Por favor adelante!

@di advierte sobre un posible retraso en el lanzamiento .

En caso de que no esté disponible cuando podamos publicar 20.3 (que esperamos que sea la próxima semana), aquí hay un plan de publicidad .

Como mencioné en un comentario en otro lugar , decidimos retrasar un poco el lanzamiento, debido a algunos problemas de CI que surgieron y debido a algunos factores externos.

En la reunión de equipo de hoy, acordamos que el lanzamiento de 20.3 probablemente sea mañana o el viernes. Puedes seguir #8936 para más.

No hice tanto alcance por paquete como había sugerido en un comentario anterior. Pero eso no significa que no hicimos divulgación. Algunas de las actividades de divulgación que hemos realizado (algunas de las cuales están catalogadas en el n.º 8511 o en esta página wiki ):

• Podcasts: Podcast.__init__ , Test & Code , FLOSS Weekly , Software Developers Journey , Real Python
• Un montón de tuits
• Un breve video de YouTube sobre los cambios.
• Correos electrónicos a los patrocinadores de PyCon, PSF y PyPI de su contacto de patrocinio de PSF, pidiéndoles que informen a sus departamentos de ingeniería sobre los próximos cambios
• Correo electrónico a pypi-announce y listas similares
• Entradas de blog como esta
• Correo electrónico a tecnología cívica y grupos/grupos de expertos similares

Durante los últimos meses, hemos recibido un flujo constante de nuevos problemas de personas que prueban el nuevo solucionador en 20.2 y 20.3 beta, pip 20.3b1 . Esos informes nos han ayudado a mejorar la resolución, corregir errores y mejorar la UX de su salida. También hemos mejorado sustancialmente la guía del usuario de "lo que está cambiando" , en parte en respuesta a los comentarios de la versión beta.

Aquí está mi plan aproximado:

* Start a discussion on discuss.python.org asking for support

* Direct folks to a Slack channel that could serve as a communication channel between everyone

* Start a document outlining some FAQ and our responses

* Include a decision tree for new issue -> triaged issue

* Share this with the channel once we have a known release date

* Try and roughly schedule volunteers to be online & triaging in the days following the release

@di Reconozco que la incertidumbre constante y los retrasos probablemente te han impedido hacer la programación. La nueva fecha de lanzamiento es mañana, lunes 30 de noviembre. Si ahora tiene un hilo de discusión y un árbol de decisiones para compartir, ¡adelante, compártalos!

pip 20.3 ha sido lanzado, ¡y tiene el nuevo solucionador por defecto! Aquí está el anuncio de lanzamiento en el blog de PSF: https://blog.python.org/2020/11/pip-20-3-release-new-resolver.html