Pip: Agregue `pip install --dry-run` o similar, para obtener el resultado de la resolución

Creado en 15 mar. 2011  ·  58Comentarios  ·  Fuente: pypa/pip

¿Cuál es el problema que resolverá esta función?

pip actualmente no tiene ningún mecanismo para que los usuarios obtengan el resultado de la resolución de dependencias de pip. Esta funcionalidad es útil para que los usuarios puedan:

  • generar algo como un "archivo de bloqueo"
  • comprobar si la instalación de un paquete rompería el entorno existente
  • Comprobación de conflictos de dependencia entre un conjunto de paquetes.
  • (¿más?)

Todo esto se puede realizar hoy, pero requiere la instalación de paquetes en algún entorno y la introspección del entorno para obtener información. Dado que toda la información relevante está disponible para pip install en tiempo de ejecución, sería útil evitar problemas con esto.

Describa la solución que le gustaría

8032 propone una opción pip install --dry-run .

7819 propone un comando pip resolve .

1345 tiene más propuestas. :)

Es probable que haya más propuestas en el rastreador de problemas que no puedo encontrar.

Soluciones alternativas

Permita que otras herramientas no pip en el ecosistema proporcionen esta funcionalidad a los usuarios. Esto es subóptimo dado que la resolución de pip no se expone públicamente de ninguna manera (las partes internas de pip no deben usarse como una biblioteca).

El ejemplo más notable es pip-tools , que es la mejor respuesta actual para cualquier usuario que busque esta funcionalidad.


Nota: @pradyunsg editó esta descripción en abril de 2020 (consulte el historial de edición para obtener más detalles) y se ocultaron algunos comentarios muy antiguos y desactualizados sobre este problema.

dependency resolution UX feature request

Comentario más útil

Alguien debe descubrir cómo presentar el resultado de la resolución primero. AFAIK, los mantenedores de pip que participan en el trabajo de resolución están haciendo esfuerzos para mejorar la resolución en este momento, por lo que esto necesitaría ayuda externa para avanzar.

Todos 58 comentarios

Hmm, tal vez necesitemos un comando para enumerar todas las versiones de paquetes disponibles en PyPI.
¿Qué piensas?

Me gusta:

$ pip list Django

1.2.4

1.2.3

1.2.2

1.2.1

1.2

1.1.3

1.1.2

1.0.4

$

Original Comment By: Hugo Lopes Tavares

Me gusta esa idea.


Original Comment By: CarlFK

Lo acabo de implementar en mi tenedor. quiero las opiniones de carljm, jezdez e ianb
antes de fusionarse.

Compruébalo aquí: https://bitbucket.org/hltbra/pip-list-
comando/conjunto de cambios/e5c135a46204


Original Comment By: Hugo Lopes Tavares

No he pensado mucho en esto, pero me parece mejor mejorar la
comando "buscar" para enumerar también las versiones (tal vez enumere todas las versiones con un indicador -v
o algo así), en lugar de agregar un nuevo comando separado. Esta funcionalidad
parece ser lógicamente una parte de la búsqueda.


Original Comment By: Carl Meyer

Estaría de acuerdo con agregar esto a la búsqueda siempre que mi otra ER esté implementada
también para que no obtenga 3000 líneas (realmente) cuando busco las versiones de django.
(hay más de 1000 visitas a "pip search django" debido a todo el django-foo
paquetes )


Original Comment By: CarlFK

Creo que es innecesario mostrar qué versión se instalaría siempre que
hay una lista de versiones disponibles, porque es fácil determinar cuál de
estos son los últimos. Además, no hay motivo para utilizar una nueva bandera para
habilite la salida de esta lista, porque la sobrecarga tiende a cero. Es
solo un pequeño cambio:
https://bitbucket.org/jumpa/pip/changeset/62076643cf33


Original Comment By: jumpa

Hola Carl, he pensado en agregar una opción al comando de búsqueda, pero mi miedo
sucedió lo que sucedió con el comando de instalación: si desea "actualizar" un
paquete, debe usar la opción "instalar"; eso es extraño, y lo sabemos.

Y si la mayoría de la gente piensa que agregar una opción para buscar es mejor, yo tampoco veo
mucho problema sobre el uso de búsqueda --versiones o búsqueda -v.


Original Comment By: Hugo Lopes Tavares

Creo que enumerar todas las versiones disponibles de forma predeterminada es demasiado detallado. Algunos
los paquetes tienen muchas versiones disponibles en pypi - diez o veinte no es raro
en absoluto. Listado de la última versión por defecto y todas las versiones con una bandera
parece razonable.

Y estoy de acuerdo con CarlFK en que también necesitamos mejoras para que la búsqueda sea
más fácil de estrechar. El problema es que dependemos de lo que nos da la API de PyPI,
lo cual no es mucho: no vamos a descargar todo PyPI y hacer una expresión regular
buscar localmente! Estaría a favor de algo como una marca --exact para buscar como
parte de este cambio, por lo que puede buscar, por ejemplo, "--exact django" y solo obtener
django mismo en tu resultado.


Original Comment By: Carl Meyer

Hola jumpa, gran idea para mostrar las versiones usando la obtenida de xmlrpc
¡conexión!

Obtuve el siguiente recorte buscando pip:

pip                       - pip installs packages.  Python packages.  An

reemplazo easy_install (versiones: 0.2, 0.2.1, 0.3, 0.3.1, 0.4, 0.5, 0.5.1,
0.6, 0.6.1, 0.6.2, 0.6.3, 0.7, 0.7.1, 0.7.2, 0.8, 0.8.1, 0.8.2)

Esta va a ser una lista tan grande de paquetes, usando muchas versiones -
porque nuestra búsqueda se preocupa por nombres y resúmenes. ¿Deberíamos preocuparnos por eso?


Original Comment By: Hugo Lopes Tavares

Como usuario final, me gusta la idea de tener un comando de lista separado*. Como el tiempo
va en un comando separado tal vez más fácil de modificar y mejorar de forma aislada. Para
hacer que un comando de lista separado sea más útil, podría indicar qué versión, si
cualquiera, está instalado actualmente.

pip list Django


1.2.4

1.2.3 installed

1.2.2

1.2.1

1.2

1.1.3

1.1.2

1.0.4

Nota: muchos administradores de paquetes populares como YUM (RedHat), pkglist (BSD),
dpkg(Debain) proporciona un indicador o comando de lista independiente.


Original Comment By: Kelsey Hightower

Carl, estuve pensando otro día sobre este tema, y ​​tengo que estar de acuerdo con
Kelsey: otro comando no esta mal.

Piense en usar una bandera para indicar que solo quiero ese nombre de paquete, y
otra bandera para indicar que quiero recuperar todas las versiones disponibles.

Es un poco extraño.

Tratemos de ilustrar:

$ pip search -v --exact Django

versus

$ pip list Django

La idea de Kelsey de mostrar qué versión está instalada simplemente mejora la lista
mando.


Original Comment By: Hugo Lopes Tavares

Hice los cambios en el comando de búsqueda.

Dado que el comando de búsqueda ya muestra la versión instalada y la última disponible, probablemente tenga más sentido aumentar el comando de búsqueda para enumerar también todas las versiones disponibles.

Aquí está mi conjunto de cambios: https://github.com/phuihock/pip/commit/46bad23b5bf31850a02803ea1ca18be5deca9db3

¿Cuál es el estado con esto? ¿Se puede ver la última versión disponible en PyPI usando pip?

¿Esto ya está implementado? Esto me ha estado molestando durante aproximadamente dos años, y me encantaría ver esto resuelto.
La búsqueda limitada combinada con un indicador de versiones parece una solución muy útil.

Solo quería agregar aquí que me encontré con este hilo mientras buscaba cómo mostrar versiones... Intenté pip search -v paquete; de ​​alguna manera eso habría tenido sentido intuitivo para mí: una descripción detallada del paquete para instalarse, incluida la información de la versión...

Acabo de darme cuenta de que esta funcionalidad aún no está implementada después de que un colega mío me preguntó al respecto. ¿Hay planes de que esté disponible en las próximas versiones de pip ?

Creo que este PR podría ser relevante, ¿eso se está trabajando actualmente?

También podría estar interesado en la charla de Linuxconf 2014 "Python Packaging 2.0: Jugando bien con otros" sobre la situación actual, así como el futuro, del empaquetado de python. El orador dijo (si entendí bien) que algunas de las limitaciones de los metadatos en pip son una consecuencia del diseño de PyPI, que originalmente se basó en CPAN, y que reelaboró ​​el backend de PyPI (mientras sigue siendo compatible con el actual usando pruebas) debería mejorar la situación. Estaba hablando principalmente de "integradores de sistemas", es decir, empaquetadores posteriores, pero supongo que eso afectaría cosas como este problema, haciéndolos más fáciles de resolver.

+1,000,000

y como esta ahora?

Ahora, ¿hay alguna forma de mostrar qué versión es la más reciente sin instalarla?
Este problema está abierto desde 2011 y el parche que he visto arriba es solo una línea. :(

Esto parece una característica menor para habilitar, ¿cómo no hay una opción equivalente a decir apt-cache madison en este momento?

También me gustaría ver la última versión del paquete PyPi cuando busque. Tener una coincidencia exacta funciona, pero uso awk como solución alternativa.

Esto también me frustró y, al ver que hay poca o ninguna esperanza, decidí que crear una alternativa podría valer la pena. Junto con este problema, implementé algunas otras funciones solicitadas (como la búsqueda de expresiones regulares y la salida coloreada, etc.). Si te interesa puedes consultarlo aquí

wget -qO- https://pypi.python.org/pypi/uWSGI | egrep -o "uwsgi-[0-9].[0-9].[0-9][0-9].tar.gz" | ordenar -u

wget -qO- https://pypi.python.org/pypi/uWSGI/json | grep '"version"'

@andreif Esto no siempre encontrará la versión correcta (pip ignora alfas, betas, candidatos de lanzamiento, etc. a menos que se proporcione --pre). Esto está más cerca (pero tampoco hay garantías):
wget -qO- https://pypi.python.org/pypi/uWSGI/json | grep -E ' {8}"[0-9."]*": \[' | sort -V | tail -n 1 | tr -d ' ":['

Ok, entonces la respuesta JSON debería incluir algo como "pre-version": "1.2.3a4" , para que uno pueda unirlos a ambos con una expresión simple.

Realmente no entiendo este problema... ¿De qué se trata esto?

  • ¿Agregar una nueva opción en pip install que haría que pip se ejecutara solo hasta la resolución de los paquetes e imprimiera los paquetes seleccionados y saliera (omitiendo la instalación)?
  • ¿Mostrando la última versión junto a los nombres de los paquetes cuando se usa pip search ?

    • ¿Poder ver la última versión de un paquete en PyPI?

Este último parece haber sido resuelto para mí y el primero probablemente debería obtener un nuevo problema dedicado.

@pradyunsg Bueno, si no recuerdo mal, necesitaba una forma sencilla de verificar qué versión está disponible actualmente (tanto la versión preliminar como la versión preliminar). Esta versión será instalada por pip install -U [--pre] .

Lo necesitaba para un script que configuraba un virtualenv. Cuando había una versión más nueva de un paquete, preguntaba si actualizar o mantener la versión actual. Entonces, este caso de uso está cubierto por la nueva búsqueda de pip.

pkg="foo"; pip install --download /dev/null --no-cache-dir --no-binary :all: "$pkg" 2>&1 | egrep -i "$pkg"'-' | head -1 | egrep -io "$pkg"'-[^ ]+' | sed 's/^'"$pkg"'-\(.*\)\.tar\.gz$/\1/g'

Publicar --download -versión obsoleta...

pkg="foo"; tmp="$(mktemp -d)"; pip download -d "$tmp" --no-cache-dir --no-binary :all: "$pkg" 2>&1 | egrep -i "$pkg"'-' | head -1 | egrep -io "$pkg"'-[^ ]+' | tr A-Z a-z | sed 's/^'"$pkg"'-\(.*\)\.tar\.gz$/\1/g'

Usando algo como:

pip install foo==

da una lista de todas las versiones disponibles (para un paquete pypi disponible válido, molécula en este caso):

Could not find a version that satisfies the requirement molecule== (from versions: 1.20.1, 1.20.3, 1.21.1, 1.22.0, 1.23.0, 1.25.0, 1.25.1, 2.10.0, 2.10.1, 2.11.0, 2.12.0, 2.12.1, 2.13.0, 2.13.1, 2.14.0, 2.15.0, 2.16.0, 2.17.0, 2.18.0, 2.18.1, 2.19.0) No matching distribution found for molecule==

pero sería bueno poder obtener la versión que se instalaría usando pip sin descargarla y/o instalarla en dev/null :-)

Acordado. Un administrador de paquetes sin esta funcionalidad es una especie de broma. Incluso su ejemplo de obtener una lista de versiones es un truco completo para compensar otra característica que este administrador de paquetes no tiene. No digo que sea malo, pero estas son cosas que deberían haber estado disponibles mucho antes de hace ocho años, cuando se creó este mismo error que se ignora por completo. Supongo que pip simplemente será reemplazado por algo que de hecho tiene más características, pero también es abominable, grotesca, monstruosamente grande y demasiado complicado. Bueno, siempre podemos escribir el nuestro.

pip-tools es una herramienta basada en pip que creo que puede ayudar con algunas de las cosas que preguntan las personas en este hilo: https://github.com/jazzband/pip-tools

Si le proporciona una lista de dependencias abstractas (es decir, sin versiones especificadas), le indicará las versiones específicas de cada requisito y dependencia para instalar.

pkg="django"; echo "$pkg" | pip-compile - --output-file - | egrep -i '^'"$pkg"'=' | cut -d '=' -f 3- es igual de tonto (más tonto si cuenta que es otra cosa que tiene que instalar [más tonto si necesita soporte de python2])

Además, todo el punto de pip-tools (& pipenv) se puede lograr con pip simple y un archivo de restricciones. ( pip install -r reqs -c constraints; pip freeze > constraints ).

¿Agregar una nueva opción en pip install que haría que pip se ejecutara solo hasta la resolución de los paquetes e imprimiera los paquetes seleccionados y saliera (omitiendo la instalación)?

Acabo de realizar una limpieza importante aquí, y este problema ahora es para rastrear/discutir este caso de uso + si/cómo cambiaría pip para acomodar esta solicitud de nueva funcionalidad.


Oculté una gran cantidad de comentarios, que van desde comentarios muy antiguos que ya no tienen el contexto relevante adjunto, hasta aquellos que incluían "trucos potenciales/pepitas de secuencias de comandos" para hacer el 90 % del trabajo para esto. Para el último grupo, absténgase de publicar más de este último aquí; hay otros foros de soporte al usuario donde esas sugerencias serían más apropiadas, no en el foro para discutir cómo implementar la corrección en la herramienta misma. :)

Disculpas a cualquiera cuyo comentario en realidad aún relevante y útil se haya ocultado; Realmente no pude descifrar el contexto de muchos comentarios y el tuyo podría haberse escondido en daños colaterales.

Como este ticket está bloqueado por el desarrollo de la resolución de dependencias (#988), pensé en mencionar aquí que el equipo está buscando ayuda de la comunidad para avanzar en ese tema.

Necesitamos comprender mejor las circunstancias en las que falla el nuevo solucionador, por lo que solicitamos a los usuarios de pip con dependencias complejas que:

  1. Pruebe el nuevo solucionador (use la versión 20.1, ejecute --unstable-feature=resolver )
  2. romperlo :P
  3. Presentar un problema

Puede encontrar más información e instrucciones más detalladas aquí

Un caso de uso que me gustaría resaltar que surgió de la experimentación en #7819 que aún no veo mencionado en este hilo es específicamente registrar URL para descargar e instalar paquetes más tarde , que es una funcionalidad ligeramente ortogonal a los archivos de bloqueo discutidos anteriormente, y es específicamente útil para consumir los resultados de una resolución de pip sin tener que descargar archivos grandes.

Hemos estado desarrollando un método de empaquetamiento para grandes aplicaciones de aprendizaje automático en Twitter, que llamamos "ipex", que se puede enviar sin contener código de terceros hasta que se ejecutan por primera vez (lo que reduce considerablemente su tamaño). En el caso de pantsbuild/pants#8793, generamos un archivo pex ejecutable que llama a la biblioteca de tiempo de ejecución de pex para resolver los requisitos (pex ejecuta pip bajo las sábanas). Actualmente estoy trabajando en un prototipo que reemplaza el paso completo de resolución de pex/pip en tiempo de ejecución con un reemplazo que registra solo las URL para descargar dists (el req.link ). Esto es extremadamente rápido en la práctica (y se puede almacenar en caché de forma muy granular), ya que la descarga y la copia de archivos para crear el archivo pex "hidratado" se pueden realizar completamente en paralelo.

Esa capacidad (de descargar e instalar toneladas de ruedas/no ruedas en paralelo) se basa además en exponer la URL de cualquier rueda o no rueda que pondríamos en un archivo de bloqueo, que no veo mencionado aquí todavía. Eso permite que los pantalones invoquen pip exactamente una vez (para resolver las URL de descarga) cuando se crea un archivo ipex deshidratado, y luego el resultado de ese paso de "resolver" con las URL se puede consumir para descargar los requisitos cuando el archivo ipex se invoca por primera vez en un completamente máquina diferente sin tener que invocar pip nuevamente.

Requirió mucho esfuerzo en #7819 propagar las URL desde las entrañas del solucionador v1 a la salida. Fue mucho menos esfuerzo la última vez que intenté hacerlo funcionar con el solucionador v2. En este momento, probablemente estemos planeando enviar alguna versión experimental de un comando --dry-run o resolve internamente que arroja URL de descarga. problemas restantes con --unstable-feature=resolver mientras tanto! :D :D

Como mencionó, el diseño del formato del archivo de bloqueo es ortogonal a la implementación del resolutor. Sin embargo, también significa que está fuera del alcance del proyecto pip actual. Ha habido debates sobre el tema (advertencia: hilo muy largo), pero teniendo en cuenta la falta de tiempo del desarrollador disponible, esto a su vez significa que es probable que no se produzcan debates serios antes de que el resolutor esté al menos estabilizado.

¡¡Gracias por el enlace!!

El domingo 24 de mayo de 2020 a las 19:34 Tzu-ping Chung [email protected]
escribió:

Como mencionó, el diseño del formato de archivo de bloqueo es ortogonal al
implementación del resolutor. Sin embargo, también significa que está fuera del alcance de la
proyecto pip actual. Ha habido debates sobre el tema.
https://discuss.python.org/t/structured-exchangeable-lock-file-format-requirements-txt-2-0/876/1
(advertencia: hilo muy largo), pero teniendo en cuenta la falta de tiempo del desarrollador
disponible, esto a su vez significa que una discusión seria probablemente no
ocurrir antes de que el resolutor esté al menos estabilizado.


Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/pypa/pip/issues/53#issuecomment-633346918 , o
darse de baja
https://github.com/notifications/unsubscribe-auth/AAJ6UT3IK65CUQGUIOGBNVDRTHKMVANCNFSM4AIQRXLA
.

@cosmicexplorer ¿Ya envió internamente esa versión experimental de un comando --dry-run o resolve ? Si es así, ¿cómo va?

Es posible que haya notado que estoy extremadamente interesado en esta función 😄

Usando algo como:

pip install foo==

da una lista de todas las versiones disponibles (para un paquete pypi disponible válido, molécula en este caso):

Could not find a version that satisfies the requirement molecule== (from versions: 1.20.1, 1.20.3, 1.21.1, 1.22.0, 1.23.0, 1.25.0, 1.25.1, 2.10.0, 2.10.1, 2.11.0, 2.12.0, 2.12.1, 2.13.0, 2.13.1, 2.14.0, 2.15.0, 2.16.0, 2.17.0, 2.18.0, 2.18.1, 2.19.0) No matching distribution found for molecule==

pero sería bueno poder obtener la versión que se instalaría usando pip sin descargarla y/o instalarla en dev/null :-)

Buen truco !! ¡¡Útil y conveniente!! Realmente impresionante !!

posibles hacks/nuggets de secuencias de comandos... absténgase de publicar más de estos últimos aquí; hay otros foros de soporte al usuario donde esas sugerencias serían más apropiadas, no en el foro para discutir cómo implementar la corrección en la herramienta misma. :)

No es por nada, de verdad, pero este es el tipo de cosas que suceden cuando dejas que un error persista durante mucho tiempo (7,56 años en el caso de mi "pepita" contribuida más recientemente, aunque este error aún abierto tiene ahora 9,25 años viejo). Las personas comparten sus soluciones.

También dudo que ocultar comentarios, incluidas las soluciones alternativas, ayude a las personas a darse cuenta de que la solución alternativa que están a punto de publicar en un comentario es innecesaria (en parte porque nadie hará clic en todos esos comentarios ocultos para ver lo que ya se ha dicho). Cuando alguien llega a un error de hace una década y no encuentra algún tipo de progreso o dirección de parte de los mantenedores, o una solución alternativa, me atrevo a decir que considerará que es necesario compartir una solución alternativa, porque hacer que otras personas sufran a través del trabajo. Ya lo he hecho en sí mismo es innecesario.

Y sí, este mismo comentario también es lo que sucede cuando sucede lo que ha hecho en respuesta a este error aún abierto.

No se preocupe, por mi parte, no agregaré más comentarios no provocados a menos que pip rompa mi script nuevamente y este error aún esté abierto.

Gracias por lo que haces. :)

@brainwane @ei8fdb Quiero marcar este problema como importante desde una perspectiva de UX - relacionado con #8377

Resumen de alto nivel basado en mi entendimiento:

  • con el nuevo resolutor, pip será menos permisivo y se negará a instalar dependencias conflictivas ( ResolutionImpossible )
  • los conflictos de dependencia pueden existir en cualquier parte del árbol de dependencia
  • las herramientas existentes (pipdeptree pip-conflict-checker) solo muestran los paquetes que ya están instalados, no los que se solicitaron, pero fallaron
  • Actualmente, no hay forma de que los usuarios averigüen dónde está el conflicto de dependencia _antes_ de que se instale un paquete, o cuándo ocurre un error ResolutionImpossible (aparte de inspeccionar manualmente las dependencias de cada proyecto)

En resumen, necesitamos una forma para que los usuarios detecten posibles conflictos de dependencia en función de sus requisitos de nivel superior (es decir, los paquetes especificados en requirements.txt o ingresados ​​directamente en la línea de comando).

Si decidimos hacer esto, el nombre de bandera propuesto ( --dry-run ) debe ser investigado/discutido.

@uranusjr @pfmoore : corríjame si me equivoqué en algo o me perdí algo basado en nuestra discusión. Gracias

@nlhkabu Estoy de acuerdo con todos sus comentarios anteriores. Sin embargo, para que quede claro, un estilo de comando --dry-run permitirá a los usuarios comprobar si va a haber un conflicto de dependencia. Pero como se describe, no ofrecerá ninguna ayuda adicional para diagnosticar por qué existe el conflicto. Por lo tanto, es básicamente un comando de instalación de "mirar antes de saltar", en contraste con el enfoque normal de "pedir perdón" donde instalamos si podemos, pero no hacemos nada e informamos el error si no.

Lo que esto no proporciona, y que es algo que, en mi opinión, sería muy útil (ya sea como un subcomando pip, o tan útil como una herramienta de terceros) es una forma de enumerar cómo se ve el árbol de dependencias desde el que está trabajando pip. . (Esto no requiere una resolución o un paso de instalación real, es "simplemente" una lista transitiva de los metadatos de dependencia de las fuentes del paquete).

Esto también podría tomar la forma de un comando pip resolve .

pip resolve es lo que la mayoría esperaría, llámalo así 😄 Eventualmente también permitiría sus propias banderas.

Gracias por la aclaración @pfmoore. Desde la perspectiva del usuario, no estoy seguro de cuánto se usa --dry-run sin resolve .

En mi opinión, no es suficiente decirles a los usuarios que obtendrán un error; también debemos brindarles suficiente información para encontrar dónde está y hacer algo al respecto.

Entonces, imagina que un usuario ejecuta --dry-run ... podríamos incluir algo como esto en la respuesta:

Conflicto de dependencia detectado. pip no podrá instalar d 1.0 y c 1.0.
El conflicto es causado por:
d 1.0 depende de E==2.0
c 1.0 depende de E==1.0
Ejecute pip resolve para inspeccionar el árbol de dependencias.

También podríamos reutilizar pip resolve en el mensaje de error ResolutionImpossible (ver #8377), lo que sería una gran victoria.

@pradyunsg , ¿tenemos un boleto separado por pip resolve ?

Además, para que quede claro, creo que el caso de uso previsto para pip resolve es (suponiendo que tenga éxito):

  1. redirigir la salida a un archivo (que generalmente se confirmará), o
  2. otras herramientas usarán/analizarán la salida

Para Twitter, usando la herramienta "ipex" como se describe en #7819, estamos creando archivos pex ejecutables usando un comando pip resolve que generará URL de descarga para todas las distribuciones resueltas en lugar de descargar cualquier cosa (que aún no se usa en producción ). Esto, junto con varias otras optimizaciones, por ejemplo, #8448, permite crear estos archivos ipex en segundos. Estos archivos ipex luego descargan todos los resultados de las distribuciones del comando pip resolve la primera vez que se ejecutan, desde el mismo centro de datos; esto permite que los archivos ipex sean megabytes en lugar de gigabytes, lo que mejora el tiempo de carga. de muchas regiones.

Básicamente, incrustamos una versión json de la salida pip resolve como un archivo en el archivo pex, y tenemos un script de arranque que lee eso para descargar las distribuciones en paralelo.

¿Algún avance en esto?

Alguien debe descubrir cómo presentar el resultado de la resolución primero. AFAIK, los mantenedores de pip que participan en el trabajo de resolución están haciendo esfuerzos para mejorar la resolución en este momento, por lo que esto necesitaría ayuda externa para avanzar.

Corríjame si me equivoco, pero lo siguiente parece ser cierto:

  • Instalar un paquete de Python implica ejecutar su setup.py.
  • Sin una opción --dry-run , no existe una manera fácil y confiable de saber qué paquetes elegirá instalar el resolutor de pip.

Por lo tanto, me parece que ejecutar pip install significa aceptar ejecutar código de una selección bastante arbitraria de paquetes PyPI en la máquina sin una forma fácil y confiable de auditarlo. Esa selección depende recursivamente de las opciones de dependencia y las prácticas de seguridad de los autores de paquetes individuales.

Depende si el proyecto y la versión que se instalará solo tiene una distribución de origen (sdist, contiene setup.py) o también ruedas (distribución construida, contiene un archivo de texto de metadatos, se instala mediante copias de archivos sin ejecutar código arbitrario)

Incluso con --dry-run, es probable que pip necesite ejecutar backends de compilación para los paquetes (lo que para las herramientas de configuración implica ejecutar setup.py) que no tienen ruedas.

¿Fue útil esta página
0 / 5 - 0 calificaciones