Înțelege modificările majore ale pachetelor Qiskit v1.0

Qiskit v1.0 folosește o structură de pachete diferită față de versiunile anterioare și va cauza probabil probleme în mediile care utilizează pachete ce nu sunt pregătite pentru Qiskit v1.0.

atenție

Nu încerca să actualizezi un mediu virtual Python existent la Qiskit v1.0 direct, fără a-l recrea.

Nu vom mai face modificări similare de pachete în viitor. Acesta este un eveniment unic, la lansarea Qiskit v1.0, tocmai pentru ca gestionarea pachetelor să fie cât mai simplă pe viitor.

Această pagină conține informații detaliate despre pachetul Qiskit anterior versiunii 1.0 și de ce am făcut aceste modificări majore de structură.

Știm că această schimbare este incomodă, dar ea restabilește Qiskit la structura simplă de pachete pe care o folosesc majoritatea pachetelor Python, ceea ce va fi mai ușor pentru utilizatori, dezvoltatori și autorii de biblioteci după finalizarea tranziției la Qiskit v1.0.

Preambul: glosar de terminologie Python pentru pachete

Pentru a explica mai bine cum era structurat vechiul metapackage Qiskit și cum s-a schimbat odată cu lansarea Qiskit v1.0, mai jos este un glosar cu termeni frecvent utilizați în contextul pachetelor Python. Cuvintele de mai jos au semnificații specifice pe care le vom folosi în acest document.

Apasă aici pentru a citi glosarul acestei pagini

• modul: Un singur fișier Python.

• pachet: Un director care conține un __init__.py și alte fișiere sau pachete pe care Python le poate citi. Acesta este codul efectiv instalat pe calculatorul tău și este ceea ce se execută când rulezi import something. Python consideră că orice director aflat pe calea de căutare poate fi importat (și va importa multe elemente suplimentare).

  Acesta nu este același obiect pe care îl pip install-ezi (care este o distribuție), dar de obicei ceea ce pip install-ezi și ceea ce import-ezi au același nume.

• submodul, subpachet: Aceștia sunt termeni impreciși, dar sunt folosiți frecvent. Prefixul sub înseamnă „conținut în interiorul unui pachet". Un submodul este un modul, iar un subpachet este un pachet, dar fac parte dintr-un pachet mai mare.

• pachet namespace: Un pachet în care alte distribuții pot instala submodule sau subpachete. Critic, nicio distribuție care contribuie la un pachet namespace nu deține neapărat toate fișierele instalate, deci poate fi dificil să îl dezinstalezi complet sau să îl actualizezi.

• distribuție: Fișierele Python comprimate, fișierele de date și metadatele care sunt descărcate când rulezi pip install something. De obicei, o distribuție conține exact un pachet și metadatele despre cum să îl instalezi (cerințele sale etc.), dar acest lucru nu este obligatoriu. O distribuție poate conține zero sau mai multe module sau pachete.

  Dacă ești familiarizat cu „manageri de pachete" din afara contextului Python, cum ar fi apt din Debian/Ubuntu sau Homebrew pe macOS, atunci ceea ce ei numesc „pachet", Python numește distribuție, și nu există o corespondență exactă pentru ceea ce Python numește pachet.

  Majoritatea surselor care discută despre pachete Python folosesc termenul pachet pentru a se referi atât la distribuții, cât și la pachete, și trebuie să te bazezi pe context pentru a înțelege sensul. În general, dacă îl import-ezi, sursa se referă la „pachet", iar dacă îl pip install-ezi, sursa se referă la „distribuție".

• cale de căutare: Când încearcă să import something, Python caută într-o listă predefinită de locuri un modul sau pachet numit something. Lista de locuri este calea de căutare. Poți vedea și modifica calea de căutare în sys.path.

• cerință: O distribuție conține informații despre alte distribuții de care depinde la instalare. Orice altă distribuție necesară este o cerință, iar managerul de pachete (de obicei pip sau conda) ar trebui să se asigure că toate cerințele sunt instalate cu versiuni compatibile.

Python este extrem de dinamic și pot apărea multe complexități; de exemplu, este posibil ca un modul sau pachet să nu corespundă fișierelor de pe disc sau să fie extensii compilate.

Calea de căutare nu este doar o căutare prin directoare, dar pentru această discuție, sunt relevante doar fișierele de pe disc. Complicațiile suplimentare nu sunt necesare pentru a înțelege problemele descrise în această secțiune, deci poți folosi modelul descris mai sus.

Vechea structură Qiskit

Istoric, Qiskit era format din multe distribuții Python: qiskit-terra, nucleul compilatorului; qiskit-aer, simulatorul de înaltă performanță; furnizorul original IBM Quantum®; și mai multe pachete acum depășite care ofereau caracteristici exploratorii algoritmice sau de rulare a experimentelor. Pentru ușurința utilizatorilor, am furnizat și o distribuție Python numită qiskit, care nu conținea cod propriu, dar determina instalarea tuturor celorlalte componente. Am numit-o metapackage, prin analogie cu concepte similare din alți manageri de pachete. Codul nucleului Qiskit se afla în qiskit-terra, care deținea rădăcina pachetului Python qiskit. Cu alte cuvinte, qiskit-terra controla ce se întâmpla când rulai import qiskit. Până la Qiskit v1.0, pachetul qiskit era un pachet namespace și conținea un al doilea pachet namespace la qiskit.providers.

Această organizare ne-a cauzat nouă și utilizatorilor noștri destul de multe probleme.

De exemplu, bibliotecile downstream care depindeau de Qiskit deseori aveau nevoie doar de nucleul compilatorului și nu necesitau restul ecosistemului extins care venea cu pip install qiskit. Prin urmare, acestea specificau corect cerința lor ca qiskit-terra. Cu toate acestea, când oamenii încercau să dezinstaleze Qiskit rulând pip uninstall qiskit, pip întâmpina probleme:

• pip nu elimină distribuțiile care nu mai sunt folosite. Deci pip uninstall qiskit nu făcea aproape nimic; nu exista cod în distribuție, deci nu era eliminat niciun cod.
• Chiar dacă ar fi eliminat codul, multe distribuții downstream ar fi rămas instalate pentru că depindeau de qiskit-terra.
• Chiar dacă qiskit-terra ar fi fost dezinstalat, ar fi putut lăsa în continuare un director qiskit importabil fără cod utilizabil, deoarece era un pachet namespace.

La instalarea sau actualizarea distribuțiilor cu o comandă pip install, pip nu ține cont nici de rezoluțiile anterioare ale cerințelor. Deoarece existau două pachete, actualizarea unui pachet care necesita actualizarea qiskit-terra ducea la un mediu invalid; pip actualiza qiskit-terra dar lăsa qiskit neatins. Emitea un avertisment la această și la toate comenzile pip install ulterioare, dar deoarece nimic nu părea defect, utilizatorii ignorau de obicei avertismentul, iar pip nu ridica o stare de eroare și nu interzicea operațiunile.

De-a lungul timpului, am eliminat elemente din metapackage-ul qiskit până când, începând cu Qiskit v0.44, rămâne doar qiskit-terra. Dintre aceste componente, qiskit-aer există în continuare și este actualizat activ, dar acum este instalat ca o distribuție separată.

De asemenea, am descurajat din ce în ce mai puternic alte biblioteci să folosească hook-urile namespace. Am eliminat ultima utilizare Qiskit a hook-urilor în pachetele non-depășite odată cu lansarea Qiskit Aer v0.11 și a noului pachet Python qiskit_aer, deși până la Qiskit v1.0 am forțat și calea namespace qiskit.providers.aer să funcționeze. Începând cu Qiskit v1.0, am eliminat posibilitatea pentru pachete de a extinde orice namespace qiskit. Astfel, pip uninstall pe distribuția corectă într-un mediu valid funcționează acum conform așteptărilor.

Noua structură Qiskit

Începând cu versiunea 1.0, Qiskit cuprinde o singură distribuție, numită qiskit, care instalează un singur pachet, tot numit qiskit, care deține tot codul conținut în directorul său. Aceasta este structura normală a codului Python și este structura cea mai simplă și mai puțin predispusă la erori.

Distribuția qiskit-terra de pe PyPI nu va fi niciodată actualizată la versiunea 1.0 sau mai mare; este complet înlocuită de qiskit. Numele qiskit-terra nu mai este implicat în instalare. Cu toate acestea, pachetul qiskit-terra nu este eliminat din PyPI și vom lăsa cea mai recentă versiune a sa în stare funcțională, astfel încât codul științific vechi și pachetele legacy pot continua mai ușor să îl folosească.

Din nefericire, din cauza moștenirii metapackage-ului și a deficiențelor din pip ca manager de pachete, nu ne este posibil să oferim o cale de actualizare complet lină pentru utilizatori la Qiskit v1.0, mai ales atâta timp cât unele pachete depind de versiuni anterioare ale Qiskit, iar altele necesită doar Qiskit v1.0+. Aceste probleme se vor diminua pe măsură ce mai mult din ecosistem migrează la Qiskit v1.0.

Unde au dispărut modulele aplicației?

Poate observi că comanda pip install qiskit nu mai include pachete precum qiskit-aer sau qiskit-nature. Odată cu eliminarea structurii metapackage, multe dintre aceste pachete au fost separate în distribuții ce trebuie instalate individual.

Înainte de lansarea Qiskit SDK v1.0, Qiskit era format din multe distribuții Python diferite, cum ar fi qiskit-terra, nucleul compilatorului; qiskit-aer, simulatorul de înaltă performanță; furnizorul original IBM Quantum®; și mai multe pachete acum depășite care ofereau caracteristici exploratorii algoritmice sau de rulare a experimentelor.

Dacă vrei să instalezi pachetele care erau incluse anterior în metapackage-ul Qiskit, vizitează ecosistemul Qiskit pentru a găsi o gamă de pachete care să se potrivească nevoilor tale. Poți citi și ghidul de migrare v1.0 pentru mai multe informații despre cum să instalezi noua distribuție.