Entender los cambios de última hora en los paquetes

Qiskit v1.0 utiliza una estructura de empaquetado diferente a la de las versiones anteriores de Qiskit y es probable que cause problemas en entornos que utilicen paquetes que no estén preparados para Qiskit v1.0.

Esta página contiene información detallada sobre el paquete pre-1.0 Qiskit y las razones por las que hemos introducido estos cambios.

Sabemos que el cambio es inconveniente, pero esto restaura Qiskit a la estructura de paquete simple que la mayoría de los paquetes Python utilizan, lo que será más fácil para los usuarios, desarrolladores y autores de bibliotecas una vez que la transición de Qiskit v1.0 esté completa.

Prefacio: glosario de terminología de embalaje de Python

Para explicar mejor cómo estaba estructurado el antiguo metapaquete Qiskit y cómo ha cambiado con el lanzamiento de Qiskit v1.0, a continuación se incluye un glosario de la jerga de empaquetado más utilizada Python. Las siguientes palabras tienen significados específicos que utilizaremos en este documento.

• Haga clic para ampliar y leer el glosario de esta página.

  • módulo : Un único archivo Python.

  • paquete : Directorio que contiene un __init__.py y otros archivos o paquetes que Python puede leer. Este es el código real instalado en su ordenador, y es lo que se ejecuta cuando se ejecuta import something. Python considera que cualquier directorio que esté en la ruta de búsqueda es algo que puede importar (e importará muchos elementos adicionales).

    Este no es el mismo objeto que pip install (que es una distribución ), pero normalmente lo que pip install y lo que import tienen el mismo nombre.

  • submódulo, subpaquete : Son términos imprecisos, pero de uso común. La subparte significa "contenido dentro de un envase". Un submódulo es un módulo y un subpaquete es un paquete, pero forman parte de un paquete mayor.

  • paquete de espacio de nombres : Un paquete que puede tener submódulos o subpaquetes instalados en él por otras distribuciones. Críticamente, ninguna distribución que contribuya a un paquete de espacio de nombres es necesariamente propietaria de todos los archivos instalados, por lo que puede ser complicado desinstalar completamente o actualizar uno.

  • distribución : Los archivos comprimidos Python, los archivos de datos y los metadatos que se descargan al ejecutar pip install something. A menudo, una distribución contiene exactamente un paquete y los metadatos sobre cómo instalarlo (sus requisitos, etc.), pero esto no es necesario. Una distribución puede contener cero o más módulos o paquetes.

    Si está familiarizado con los "gestores de paquetes" fuera del contexto de Python, como apt de Debian / Ubuntu o Homebrew en macOS, entonces lo que ellos llaman un "paquete", Python lo llama una distribución, y no hay una coincidencia exacta para lo que Python llama un paquete.

    La mayoría de las fuentes que hablan del empaquetado en Python utilizan el término paquete para referirse tanto a las distribuciones como a los paquetes, y hay que remitirse al contexto para entender lo que se quiere decir. En general, si se escribe import , la fuente significa "paquete", y si se escribe pip install , la fuente significa "distribución".

  • ruta de búsqueda : Al intentar import something, Python busca en una lista predefinida de lugares un módulo o paquete llamado something. La lista de lugares es la ruta de búsqueda. Puede ver y modificar la ruta de búsqueda en sys.path.

  • requisito : Una distribución contiene información sobre otras distribuciones de las que depende cuando se instala. Cualquier otra distribución que sea necesaria es un requisito, y el gestor de paquetes (normalmente pip o conda) debe asegurarse de que todos los requisitos se instalan con versiones compatibles.

Python es muy dinámico, y pueden surgir muchas complejidades; por ejemplo, es posible que un módulo o paquete no se corresponda con archivos en disco, o que sean extensiones compiladas.

La ruta de búsqueda no es sólo una búsqueda sobre directorios, pero para esta discusión, sólo los archivos en disco son relevantes. No son necesarias más complicaciones para entender los problemas descritos en esta sección, por lo que puede utilizar el modelo descrito anteriormente.

La antigua estructura Qiskit

Históricamente, Qiskit estaba compuesto por muchas distribuciones de Python : qiskit-terra el núcleo del compilador, qiskit-aer, el simulador de alto rendimiento, el proveedor original IBM Quantum® y varios paquetes ya obsoletos que proporcionaban funciones algorítmicas exploratorias o de ejecución de experimentos. Para facilidad del usuario, también proporcionamos una distribución de Python llamada qiskit, que no contenía código propio, pero hacía que se instalaran todos los demás componentes. Lo llamamos metapaquete, por analogía con conceptos similares de otros gestores de paquetes. El código del núcleo de Qiskit vivía en qiskit-terra, que poseía la raíz del paquete Python qiskit. En otras palabras, qiskit-terra controlaba lo que ocurría al ejecutar import qiskit. Hasta Qiskit v1.0, el paquete qiskit era un paquete de espacio de nombres y contenía un segundo paquete de espacio de nombres en qiskit.providers.

Esta organización nos causó bastantes problemas a nosotros y a nuestros usuarios.

Por ejemplo, las bibliotecas derivadas que dependían de Qiskit a menudo sólo necesitaban el núcleo del compilador y no el resto del amplio ecosistema incluido en pip install qiskit. Por tanto, especificarían correctamente su requisito como qiskit-terra. Sin embargo, cuando la gente intentó desinstalar Qiskit ejecutando pip uninstall qiskit, pip encontró problemas:

• pip no elimina las distribuciones que ahora no se utilizan. Así que pip uninstall qiskit no hizo casi nada; no había código en la distribución, así que no se eliminó ningún código.
• Aunque eliminara el código, muchas distribuciones posteriores seguirían instaladas porque dependen de qiskit-terra.
• Incluso si qiskit-terra fuera desinstalado, aún podría dejar un directorio qiskit importable sin código utilizable, porque era un paquete namespace.

Al instalar o actualizar distribuciones con un comando pip install , pip tampoco tiene en cuenta las resoluciones de requisitos anteriores. Como había dos paquetes, la actualización de un paquete que requería la actualización de qiskit-terra provocaba un entorno no válido; pip actualizaba qiskit-terra pero dejaba qiskit intacto. Emitió una advertencia sobre éste y todos los comandos pip install posteriores, pero como nada parecía roto, los usuarios normalmente ignoraban la advertencia, y pip no lanzaba un estado de error ni prohibía las operaciones.

Con el tiempo, hemos ido eliminando elementos del metapaquete qiskit hasta que, a partir de Qiskit v0.44, sólo queda qiskit-terra . De estos componentes, qiskit-aer sigue existiendo y se actualiza activamente, pero ahora se instala como una distribución independiente.

Del mismo modo, desaconsejamos cada vez más que otras bibliotecas utilicen los ganchos del espacio de nombres. Eliminamos el último uso de Qiskit de los ganchos en paquetes no obsoletos con el lanzamiento de Qiskit Aer v0.11 y su nuevo paquete qiskit_aer Python, aunque hasta Qiskit v1.0 también forzamos la ruta del espacio de nombres qiskit.providers.aer para que funcionara. A partir de Qiskit v1.0, hemos eliminado la posibilidad de que los paquetes amplíen cualquier espacio de nombres de qiskit . Así, pip uninstall en la distribución correcta en un entorno válido funciona ahora como se espera.

La nueva estructura de Qiskit

A partir de la versión 1.0, Qiskit comprende una única distribución, denominada qiskit, que instala un único paquete, también denominado qiskit, propietario de todo el código contenido en su directorio. Esta es la estructura normal del código Python, y es la más sencilla y menos propensa a errores.

La distribución qiskit-terra en PyPI nunca se actualizará a la versión 1.0 o posteriores; queda totalmente sustituida por qiskit. El nombre qiskit-terra ya no aparece en la instalación. Sin embargo, el paquete qiskit-terra no se eliminará de PyPI, y dejaremos su versión más reciente en estado operativo, para que el código científico antiguo y los paquetes heredados puedan seguir utilizándolo más fácilmente.

Desgraciadamente, debido al legado de los metapaquetes y a las deficiencias de pip como gestor de paquetes, no nos es posible realizar una ruta de actualización completamente fluida para los usuarios a Qiskit v1.0, especialmente mientras algunos paquetes dependan de versiones anteriores de Qiskit, y algunos requieran sólo Qiskit v1.0+. Estos problemas disminuirán a medida que el ecosistema migre a Qiskit v1.0.

¿Dónde están los módulos de la aplicación?

Es posible que observe que el comando pip install qiskit ya no incluye paquetes como qiskit-aer o qiskit-nature. Con la eliminación de la estructura de metapaquetes, muchos de estos paquetes se dividieron en distribuciones que deben instalarse por separado.

Antes de la publicación de Qiskit SDK v1.0, Qiskit se componía de muchas distribuciones diferentes Python, como qiskit-terra, el núcleo del compilador; qiskit-aer, el simulador de alto rendimiento; el proveedor original IBM Quantum®; y varios paquetes ya obsoletos que proporcionaban características particulares de exploración algorítmica o de ejecución de experimentos.

Si deseas instalar los paquetes que antes se incluían en el metapaquete de Qiskit, visita el ecosistema de Qiskit para encontrar una amplia variedad de paquetes que se adapten a tus necesidades. También puedes consultar la guía de migración de v1.0 para obtener más información sobre cómo instalar la nueva distribución.