Comprendre les changements de paquets majeurs de Qiskit v1.0

Qiskit v1.0 utilise une structure d'empaquetage différente des versions précédentes de Qiskit et causera probablement des problèmes dans les environnements qui utilisent des paquets non compatibles avec Qiskit v1.0.

attention

N'essaie pas de mettre à niveau un environnement virtuel Python existant vers Qiskit v1.0 directement.

Nous ne ferons pas de changements d'empaquetage aussi importants à l'avenir. C'est un événement unique, lors de la sortie de Qiskit v1.0, spécifiquement pour que notre gestion des paquets soit aussi simple que possible à l'avenir.

Cette page contient des informations détaillées sur le paquet Qiskit antérieur à la version 1.0 et sur les raisons pour lesquelles nous avons effectué ces changements d'empaquetage majeurs.

Nous savons que ce changement est contraignant, mais il restaure Qiskit dans la structure de paquet simple que la plupart des paquets Python utilisent, ce qui sera plus facile pour les utilisateurs, les développeurs et les auteurs de bibliothèques une fois la transition vers Qiskit v1.0 terminée.

Préambule : glossaire de la terminologie d'empaquetage Python

Pour mieux expliquer la structure de l'ancien métapaquet Qiskit et la façon dont elle a évolué avec la sortie de Qiskit v1.0, voici un glossaire des termes courants liés à l'empaquetage Python. Les mots suivants ont des significations précises que nous utiliserons dans ce document.

Clique ici pour lire le glossaire de cette page

• module : Un fichier Python unique.

• paquet : Un répertoire contenant un __init__.py et d'autres fichiers ou paquets que Python peut lire. C'est le code réel tel qu'il est installé sur ton ordinateur, et c'est ce qui s'exécute quand tu lances import something. Python considère tout répertoire figurant dans le chemin de recherche comme quelque chose que tu peux importer (et importera de nombreux éléments supplémentaires).

  Ce n'est pas le même objet que tu installes avec pip install (qui est une distribution), mais en général ce que tu installes avec pip install et ce que tu importes ont le même nom.

• sous-module, sous-paquet : Ces termes sont imprécis, mais couramment utilisés. La partie sub signifie « contenu à l'intérieur d'un paquet ». Un sous-module est un module et un sous-paquet est un paquet, mais ils font partie d'un paquet plus grand.

• paquet d'espace de noms : Un paquet dans lequel d'autres distributions peuvent installer des sous-modules ou des sous-paquets. Il est important de noter qu'aucune distribution contribuant à un paquet d'espace de noms ne possède nécessairement tous les fichiers installés, ce qui peut rendre difficile la désinstallation complète ou la mise à niveau.

• distribution : Les fichiers Python compressés, les fichiers de données et les métadonnées téléchargés lors de l'exécution de pip install something. Souvent, une distribution contient exactement un paquet et les métadonnées sur la façon de l'installer (ses dépendances, etc.), mais ce n'est pas obligatoire. Une distribution peut contenir zéro ou plusieurs modules ou paquets.

  Si tu es familier avec les « gestionnaires de paquets » en dehors du contexte Python, comme apt de Debian/Ubuntu ou Homebrew sur macOS, ce qu'ils appellent un « paquet », Python l'appelle une distribution, et il n'y a pas d'équivalent exact à ce que Python appelle un paquet.

  La plupart des sources traitant de l'empaquetage Python utilisent le terme paquet pour désigner à la fois les distributions et les paquets, et tu dois te référer au contexte pour comprendre ce qui est visé. En général, si tu l'importes, la source désigne un « paquet », et si tu le fais avec pip install, la source désigne une « distribution ».

• chemin de recherche : Lorsqu'il essaie d'importer quelque chose, Python parcourt une liste prédéfinie d'emplacements à la recherche d'un module ou d'un paquet portant ce nom. Cette liste d'emplacements est le chemin de recherche. Tu peux voir et modifier le chemin de recherche dans sys.path.

• dépendance : Une distribution contient des informations sur les autres distributions dont elle dépend lors de son installation. Toute autre distribution nécessaire est une dépendance, et le gestionnaire de paquets (généralement pip ou conda) doit s'assurer que toutes les dépendances sont installées avec des versions compatibles.

Python est très dynamique et de nombreuses complexités peuvent survenir ; par exemple, il est possible qu'un module ou un paquet ne corresponde pas à des fichiers sur le disque, ou qu'ils soient des extensions compilées.

Le chemin de recherche n'est pas uniquement une recherche dans des répertoires, mais pour cette discussion, seuls les fichiers sur le disque sont pertinents. Les complications supplémentaires ne sont pas nécessaires pour comprendre les problèmes décrits dans cette section, donc le modèle décrit ci-dessus suffit.

L'ancienne structure de Qiskit

Historiquement, Qiskit était composé de nombreuses distributions Python : qiskit-terra, le cœur du compilateur ; qiskit-aer, le simulateur haute performance ; le fournisseur IBM Quantum® original ; et plusieurs paquets désormais obsolètes fournissant des fonctionnalités exploratoires particulières d'algorithmes ou d'exécution d'expériences. Pour faciliter la vie des utilisateurs, nous fournissions également une distribution Python appelée qiskit, qui ne contenait aucun code propre, mais provoquait l'installation de tous les autres composants. Nous appelions cela le métapaquet, par analogie à des concepts similaires dans d'autres gestionnaires de paquets. Le code du cœur de Qiskit se trouvait dans qiskit-terra, qui possédait la racine du paquet Python qiskit. En d'autres termes, qiskit-terra contrôlait ce qui se passait quand tu exécutais import qiskit. Jusqu'à Qiskit v1.0, le paquet qiskit était un paquet d'espace de noms et contenait un second paquet d'espace de noms à qiskit.providers.

Cette organisation nous a causé, à nous et à nos utilisateurs, un bon nombre de problèmes.

Par exemple, les bibliothèques en aval qui dépendaient de Qiskit n'avaient souvent besoin que du cœur du compilateur, sans nécessiter le reste du vaste écosystème fourni par pip install qiskit. Elles spécifiaient donc correctement leur dépendance comme qiskit-terra. Cependant, lorsque les utilisateurs essayaient de désinstaller Qiskit en exécutant pip uninstall qiskit, pip rencontrait des problèmes :

• pip ne supprime pas les distributions devenues inutilisées. Donc pip uninstall qiskit ne faisait presque rien ; il n'y avait pas de code dans la distribution, donc aucun code n'était supprimé.
• Même si du code était supprimé, de nombreuses distributions en aval resteraient installées car elles dépendaient de qiskit-terra.
• Même si qiskit-terra était désinstallé, un répertoire qiskit importable mais sans code utilisable pouvait subsister, car il s'agissait d'un paquet d'espace de noms.

Lors de l'installation ou de la mise à niveau de distributions avec pip install, pip ne tient pas non plus compte des résolutions de dépendances précédentes. Comme il y avait deux paquets, la mise à niveau d'un paquet nécessitant la mise à niveau de qiskit-terra créait un environnement invalide ; pip mettait à niveau qiskit-terra mais laissait qiskit intact. Il affichait un avertissement lors de cette opération et de tous les pip install suivants, mais comme rien ne semblait cassé, les utilisateurs ignoraient généralement cet avertissement, et pip n'affichait pas d'erreur ni n'interdisait les opérations.

Au fil du temps, nous avons retiré des éléments du métapaquet qiskit jusqu'à ce que, à partir de Qiskit v0.44, seul qiskit-terra reste. Parmi ces composants, qiskit-aer existe toujours et est activement mis à jour, mais il est désormais installé comme une distribution séparée.

De même, nous avons de plus en plus fortement déconseillé aux autres bibliothèques d'utiliser les hooks d'espace de noms. Nous avons supprimé la dernière utilisation Qiskit de ces hooks dans les paquets non obsolètes avec la sortie de Qiskit Aer v0.11 et son nouveau paquet Python qiskit_aer, bien que jusqu'à Qiskit v1.0 nous ayons également forcé le chemin d'espace de noms qiskit.providers.aer à fonctionner. À partir de Qiskit v1.0, nous avons supprimé la possibilité pour les paquets d'étendre tout espace de noms qiskit. Ainsi, pip uninstall sur la bonne distribution dans un environnement valide fonctionne désormais comme prévu.

La nouvelle structure de Qiskit

À partir de la version 1.0, Qiskit comprend une seule distribution, appelée qiskit, qui installe un unique paquet, également appelé qiskit, qui possède tout le code contenu dans son répertoire. C'est la structure normale du code Python, et c'est la structure la plus simple et la moins sujette aux erreurs.

La distribution qiskit-terra sur PyPI ne sera jamais mise à jour vers la version 1.0 ou au-delà ; elle est entièrement remplacée par qiskit. Le nom qiskit-terra n'est plus impliqué dans l'installation. Cependant, le paquet qiskit-terra n'est pas supprimé de PyPI, et nous laisserons sa version la plus récente dans un état fonctionnel, afin que l'ancien code scientifique et les paquets hérités puissent continuer à l'utiliser plus facilement.

Malheureusement, en raison de l'héritage du métapaquet et des lacunes de pip en tant que gestionnaire de paquets, il ne nous est pas possible de proposer une migration totalement fluide vers Qiskit v1.0 pour les utilisateurs, en particulier quand certains paquets dépendent de versions antérieures de Qiskit et que d'autres nécessitent uniquement Qiskit v1.0+. Ces problèmes s'atténueront à mesure que davantage de l'écosystème migrera vers Qiskit v1.0.

Où sont passés les modules applicatifs ?

Tu remarqueras peut-être que la commande pip install qiskit n'inclut plus des paquets tels que qiskit-aer ou qiskit-nature. Avec la suppression de la structure de métapaquet, beaucoup de ces paquets ont été séparés en distributions qui doivent être installées séparément.

Avant la sortie du SDK Qiskit v1.0, Qiskit était composé de nombreuses distributions Python différentes, telles que qiskit-terra, le cœur du compilateur ; qiskit-aer, le simulateur haute performance ; le fournisseur IBM Quantum® original ; et plusieurs paquets désormais obsolètes fournissant des fonctionnalités exploratoires particulières d'algorithmes ou d'exécution d'expériences.

Si tu souhaites installer les paquets qui étaient précédemment inclus dans le métapaquet Qiskit, visite l'écosystème Qiskit pour trouver une gamme de paquets adaptés à tes besoins. Tu peux également lire le guide de migration v1.0 pour plus d'informations sur la façon d'installer la nouvelle distribution.