Contribuer à Qiskit¶

Qiskit est un projet open-source dont l’objectif est de donner accès à l’informatique quantique à tous. Cette page décrit comment vous pouvez rejoindre la communauté Qiskit.

Tout est là¶

Le code de Qiskit se trouve dans ce dépôt : Qiskit GitHub organization. Il regroupe les projets composant Qiskit, et en particulier

Comment démarrer¶

Découvrez comment les membres de la communauté Qiskit

Signaler des anomalies et faire des demandes d’amélioration¶

Lorsque vous rencontrez une anomalie, ouvrez un ticket (issue) dans l’outil de suivi approprié :

Elément	Outil de suivi des anomalies
qiskit-terra	https://github.com/Qiskit/qiskit-terra/issues
qiskit-aer	https://github.com/Qiskit/qiskit-aer/issues
qiskit-ignis	https://github.com/Qiskit/qiskit-ignis/issues
qiskit-aqua	https://github.com/Qiskit/qiskit-aqua/issues
Documentations ou meta-package de Qiskit	https://github.com/Qiskit/qiskit/issues

Si vous avez l’idée d’une nouvelle fonctionnalité, ouvrez un ticket d’amélioration (Enhancement issue) dans l’outil de suivi approprié. Créer un ticket entraine automatiquement l’ouverture d’une discussion avec l’équipe autour de cette idée : comment elle s’intègre au projet, comment elle peut être implémentée, etc.

Contribuer au Code¶

Guide de style¶

Pour favoriser une manière de coder cohérente et consistante dans l’ensemble du projet, nous utilisons Pylint et pycodesytle Pour vérifier que les différentes contributions respectent le style de codage du projet, exécutez la commande: tox -elint

Accord de licence Contributeur¶

Avant de soumettre un nouveau code, tous les contributeurs doivent signer un Accord de Licence (contributor license agreement -CLA-). En signant ce CLA, vous attestez que vous êtes l’auteur de la contribution et que vous contribuez de manière gratuite, en suivant les termes de la licence Apache-2.0.

Lorsque vous contribuez au projet Qiskit via une nouvelle demande d’ajout, un robot vérifie si vous avez signé le CLA. Si tel n’est pas le cas, le bot vous invitera à signer cet accord, via un lien automatiquement généré. Le document individual CLA est disponible au format PDF.

Note

Si votre contribution est liée à votre emploi ou qu’elle est la propriété de votre employeur, vous devrez très probablement signer en plus l’accord suivant: corporate CLA et envoyer cet accord par eMail à: <qiskit@us.ibm.com>.

Pull Requests¶

Nous utilisons Pousser des requêtes GitHub (pull request) pour accepter de nouvelles contributions.

Même si cela n’est pas formellement obligatoire, ouvrir un ticket (issue) lorsque vous corrigez une anomalie ou développez une nouvelle fonctionnalité est une étape importante pour initier une discussion avec la communauté sur votre travail. Le ticket nous offre un endroit partagé pour réfléchir sur l’idée et voir comment travailler ensemble. Si vous avez besoin d’aide, que vous souhaitez discuter avec d’autres membres de l’équipe, vous pourrez aussi faire référence à ce ticket.

Si vous écrivez du code et que vous avez besoin d’aide pour le terminer ou que vous souhaitez le partager en cours de développement, vous pouvez ouvrir une requête de type Work in Progress. Lorsque vous créez une fusio-demande (ou pull request), ajoutez en tête du titre les caractères [WIP] (pour Work In Progress). Cela indiquera aux re-lecteurs que le code n’est pas terminé et qu’il est sujet à changements. Cela signifie aussi que vous n’intègrerai pas ce nouveau code tant qu’il n’est pas terminé. Vous, ou un re-lecteur, pouvez supprimer le tag [WIP] lorsque le code est prêt à être revu et intégré.

Revue de code¶

La revue de code est faite librement et est accessible à tous. Même si l’intégration d’un code final est réservée à un sous ensemble d’utilisateurs (maintainers), les commentaires de toute la communauté sont extrêmement profitables au projet. C’est aussi un excellent moyen d’apprendre. Vous pouvez accéder à l’ensemble des pull requests ouvertes ici:

Elément	Pull Requests
qiskit-terra	https://github.com/Qiskit/qiskit-terra/pulls
qiskit-aer	https://github.com/Qiskit/qiskit-aer/pulls
qiskit-ignis	https://github.com/Qiskit/qiskit-ignis/pulls
qiskit-aqua	https://github.com/Qiskit/qiskit-aqua/pulls
Documentations ou meta-package de Qiskit	https://github.com/Qiskit/qiskit/pulls

Les Commit Messages¶

Tout changement doit être documenté et expliqué dans le « Commit message ». Documenter une modification est aussi importante que la modification elle-même. Cette documentation, non seulement, aide pendant la revue de code mais permet de garder l’historique des modifications dans le référentiel git. Un Commit message détaillé rendra la revue de code plus simple et fournira un contexte au futur lecteur du code correspondant. Lorsque vous documentez un Commit, gardez en mémoire les points suivants :

Ne supposez pas que le re-lecteur comprend le problème initial.

Il est vrai que, dans la majorité des cas, lire un ticket d’anomalie permet de comprendre l’origine de cette anomalie et comment elle a été identifiée. Cela ne dispense pas le Commit Message de décrire clairement l’origine de l’anomalie, comment elle a été détectée et corrigée. Il doit être possible de retrouver cette information sans devoir retourner au ticket associé à l’anomalie.

Ne supposez pas que le code soit évident ou auto-documenté.

Ce qui est évident pour une personne ne l’est sans doute pas pour une autre. Documentez toujours l’origine du problème et comment il a été corrigé. Expliquez votre code.

Décrivez pourquoi une modification est réalisée.

Il est important de documenter comment le code a été écrit. Mais on oublie souvent de décrire pourquoi on a choisi cette option plutôt qu’une autre pour résoudre le problème. Bien entendu, il faut décrire la structure du code produit. Mais il faut aussi documenter les intensions, les motivations qui sous-tendent ces changements.

Lisez le Commit message pour vérifier s’il fait référence à l’amélioration de la structure générale du code.

Souvent, lors de la rédaction du Commit message, il apparait évident que le changement en cours aurait dû être divisé en plusieurs changements plus ciblés. N’hésitez pas à faire machine arrière et à découper vos modifications en plusieurs, plus restreintes et à faire autant de Commit que nécessaires.

Assurez-vous de la complétude de l’information en cas de revue ultérieure.

Lorsque Github envoie des emails d’alertes pour les soumissions de nouvelles pull requests, ces emails contiennent (le plus souvent) uniquement le Commit message et la liste des fichiers modifiés. Le Commit message doit donc contenir suffisamment d’informations pour qu’un re-lecteur retrouve facilement, dans l’immense volume de changements composant un projet, la modification qu’il souhaite revoir.

La première ligne du commentaire est la plus importante.

Dans les commits Git, la première ligne du Commit message a une signification particulière. Cette première ligne sert de titre par défaut à la pull request, de sujet aux emails de notification, aux messages d’annotation git, aux messages d’intégration (merge) et dans bien d’autres endroits. Elle doit donc à la fois résumer le changement lui-même mais aussi indiquer quelle partie du code est affectée.

De plus, cette première ligne devient une entrée dans le référentiel de changements (changelog), à condition que la PR soit incluse dans le changelog. Il est essentiel que vous écriviez des commentaires clairs et succints.

Décrivez les limitations de votre code.

Si le code en cours de changement nécessite de futures améliorations ou présente des limitations identifiées, mentionnez le dans le Commit message. Cela montrera au re-lecteur qu’une vision plus large des besoins est prise en considération. Le court terme et le moyen terme seront ainsi clairement exprimés.

Faites référence aux tickets d’incidents (issue).

Si les modifications sont liées à un incident, n’oubliez pas de le préciser dans le Commit message. Utilisez la syntaxe suivante

Fixes #1234

si votre code corrige l’anomalie (GitHub fermera le ticket lorsque la PR sera intégrée).

La règle principale est :

Le Commit message doit contenir toutes les informations requises pour comprendre et vérifier les corrections associées.

Documenter votre code¶

Si vous modifiez un élément, prenez soin de mettre à jour les docstrings et la documentation associée dans le répertoire docs/apidocs. Pour produire, localement la documentation, exécutez la commande tox -edocs pour compiler et construire la documentation et sauvegardez le résultat dans docs/_build/html.

Si vous avez un problème avec la documentation qui se trouve dans le répertoire Qiskit/qiskit,, vous pouvez ouvrir un ticket documentation. Procédez ainsi si vous constatez une anomalie dans la doc, si vous souhaitez documenter une nouvelle fonctionnalité ou si vous estimez que de nouvelles informations doivent compléter la documentation existante.

Choisir ses premières contributions¶

Si vous souhaitez contribuer à Qiskit mais que vous ne savez pas par où commencer, le marquage (label) good first issue posé sur certains tickets, vous indique les sujets particulièrement appropriés aux nouveaux contributeurs. En d’autres termes, il n’est pas besoin d’être un spécialiste de Qiskit pour participer au développement du projet.

Politique de dépréciation¶

Les utilisateurs de Qiskit doivent pouvoir savoir si les fonctions ou les APIs qu’ils utilisent seront toujours supportées demain. Savoir sous quelles conditions un projet peut supprimer (ou modifier sans compatibilité ascendante) une fonctionnalité, est très important pour les développeurs. La politique décrite ci-dessous explique comment les APIs et le fonctionnalités sont dépréciées ou supprimées dans Qiskit :

1. Features, APIs, or configuration options are marked deprecated in the code. Appropriate DeprecationWarning class warnings will be sent to the user. The deprecated code will be frozen and receive only minimal maintenance (just so that it continues to work as-is).

2. Un chemin de migration sera documenté pour les utilisateurs de la fonctionnalité. Ce chemin sera décrit dans les release notes associées à la dépréciation et dans celles associées à la suppression de la fonction à la fin du cycle de dépréciation. Si cela est possible, le message d’avertissement décrira lui-aussi le chemin de migration. Un chemin de migration peut se résumer à « N’utilisez plus cette fonction », mais dans ce cas, il est important d’évaluer l’impact de la modification et d’envisager une date d’obsolescence raisonnable, qui tienne compte de l’importance de la fonctionnalité concernée.

3. An obsolescence date for the feature will be set. The feature must remain intact and working (although with the proper warning being emitted) in all releases pushed until after that obsolescence date. At the very minimum, the feature (or API, or configuration option) should be marked as deprecated (and continue to be supported) for at least three months of linear time from the release date of the first release to include the deprecation warning. For example, if a feature were deprecated in the 0.9.0 release of Terra, which was released on August 22, 2019, then that feature should still appear in all releases until at least November 22, 2019. Since releases do not occur at fixed time intervals, a deprecation warning may only occur in one release prior to removal.

Notez que ce délai est un minimum. Pour des fonctions majeures, il est recommandé que la fonction reste disponible encore au moins six mois. La stabilité d’une branche de version implique que les suppressions de fonctions n’interviennent que dans des versions mineures.

Avertissements de dépréciation¶

La façon correcte de lever un warning de dépréciation est d’utiliser la fonction warn du module warnings module disponible dans la librairie standard de Python. La classe warning est DeprecationWarning. Voici un exemple d’appel

import warnings

def foo(input):
    warnings.warn('The qiskit.foo() function is deprecated as of 0.9.0, and '
                  'will be removed no earlier than 3 months after that '
                  'release date. You should use the qiskit.bar() function '
                  'instead.', DeprecationWarning, stacklevel=2)

Notez l’argument kwarg stack_level dans la fonction warn(). Le plus souvent, stack_level devrait être positionné à 2, indiquant que l’on souhaite montrer l’appelant conduisant au warning. Dans l’exemple ci-dessus, ce contexte serait l’appelant de la fonction foo(). Si vous ne positionnez pas cet argument de cette façon, le warning indiquera qu’il est engendré par la ligne dans la fonction foo(), ce qui est peu intéressant pour celui qui souhaite comprendre l’origine du warning. Cependant, cette valeur peut être différente de deux, en fonction de l’origine de l’appel à warn(). Par exemple, si le warning est toujours appelé d’une méthode privée avec un seul appelant, il est bon de poser stack_level=3.

Politique de la branche stable¶

La branche dite stable est la source saine des différentes corrections des anomalies majeures identifies et corrigées dans le master depuis la dernière version. Toute modification de cette branche stable doit se faire en évaluant en premier le risque lié à la modification et en le comparant au bénéfices obtenus. Seuls quelques changements bien identifiés doivent être inclus dans cette branche stable. Une correction majeure mais adressant une anomalie critique ou bien une correction triviale pour une fonctionnalité très mineure peuvent être considérées. Dans tous les cas, il est bon de considérer les points suivants :

Le risque de régression: même la plus petite des modifications peut avoir un impact sur la stabilité du code. Et l’objectif est bien entendu de garder la branche stable la plus sûre possible.
Le bénéfice utilisateur: Sommes-nous en train de corriger quelque chose constaté par les utilisateurs? Cela apporte t’il un réel gain pour eux?
La portée de la correction: Si cette correction règle un problème important mais qu’elle engendre des modifications fortes du code, imaginer une correction plus légère doit être envisagé.
La correction est-elle déjà dans le Master? Une modification peut être le backport d’une correction déjà présente dans le Master, ou bien la correction n’a peut-être aucun sens dans le Master.

Procédure de rétroportage (Backporting):¶

Lorsqu’une correction est réalisée du Master vers la branche stable, il est important d’en garder la trace dans le Master. Lorsque vous créez la branche recevant la PR stable, utilisez la commande:

$ git cherry-pick -x $master_commit_id

Bien entendu, cette méthode ne fonctionne que pour les patches simples issus du Master. Si vous devez retroporter (backport) un ensemble conséquent de modifications (commits), issues du Master, faite le manuellement. Dans ce cas, ajoutez

Backported from: #master pr number

pour conserver l’origine de la modification.

Quoi qu’il en soit, toute modification dans être documentée dans le message de Commit. Cela facilitera la revue de code.

Etiquettes de Backport¶

Les anomalies ou PR avec l’étiquette stable backport potential sont celles candidates à un backportage dans le Master. Une fois l’intégration réalisée, le tag doit être supprimé.

Les anomalies ou PR avec l’étiquette stable backport potential sont celles candidates à un backportage dans le Master. Une fois l’intégration réalisée, le tag doit être supprimé. Ajoutez [Stable] dans le titre de la PR envoyée à la branche stable pour confirmer la pertinence de cette PR. N’oubliez pas d’ajouter le numéro de la PR dans le Master.

Contribuer à la Documentation¶

La documentation Qiskit est conforme aux principes de docs as code , issus des commentaires du code Qiskit et prenant exemple sur style of API documentation.

La documentation est produite à partir de la branche de Qiskit/qiskit/docs et repose sur Sphinx. L’essentiel de la documentation, décrite ici API Reference, est issue des commentaires de code des répertoires listés dans Tout est là.

Structure de la Documentation¶

La documentation de Qiskit est autant que possible intégrée dans les docstrings. Cela rend les ajouts et corrections plus faciles pendant le développement. La document vit avec les changements de code. Il y a trois niveaux de documentation dans Terra :

Les fichiers .rst``dans le répertoire ``docs/apidocs

Ces fichiers permettent de préciser à Sphinx quels modules sont à intégrer dans la documentation finale. Ils contiennent deux types d’information : une référence interne ou une référence croisée à un autre module, utilisé comme line interne à l’intérieur de la documentation, et une directive automodule utilisée pour parser les docstrings via un chemin d’import (import path). Par exemple, le fichier dagcircuit.rst contient:

.. _qiskit-dagcircuit:


.. automodule:: qiskit.dagcircuit
   :no-members:
   :no-inherited-members:
   :no-special-members:

Le fichier qiskit.rst est différent et contient la table des matières. Si vous créez un fichier .rst pour documenter un nouveau module, assurez-vous de l’ajouter au fichier toctree.

Le module docstring

Le docstring se trouve au niveau module, tel que défini dans la directive automodule du fichier rst. Si le module spécifié est un directory/namespace, le docstring doit être défini dans le fichier __init__.py``de ce répertoire. Ce docstring contient plus de détails sur le module documenté. Le docstring permet de préciser toutes les classes et fonctions des APIs publiques contenues dans ce module. Ceci est de fait réalisé via les directives `autosummary directive <https://www.sphinx-doc.org/en/master/usage/extensions/autosummary.html>`__ (ou directement dans `autodoc directives <http://www.sphinx-doc.org/en/master/usage/extensions/autodoc.html>`__ si le module est simple, comme c'est le cas pour ``qiskit.execute). La directive autosummary est utilisée pour documenter automatiquement une liste d’éléments Python (classes, fonctions, etc.) sans avoir à appeler manuellement des directives autodoc pour chacun d’eux Le docstring permet de fournir une vue haut-niveau des fonctionnalités du module. Il est recommandé de grouper les différents composants des APIs publiques de ce module dans des sous-sections.

Par exemple, pour le module dagcircuit déjà évoqué, le contenu du docstring dans qiskit/dagcircuit/__init__.py serait

"""
=======================================
DAG Circuits (:mod:`qiskit.dagcircuit`)
=======================================
.. currentmodule:: qiskit.dagcircuit
DAG Circuits
============
.. autosummary::
   :toctree: ../stubs/
   DAGCircuit
   DAGNode
Exceptions
==========
.. autosummary::
   :toctree: ../stubs/
   DAGCircuitError
"""

Note

Ce n’est qu’un exemple et le module docstring pour le module dagcircuit peut se différencier de cela.

La chaîne de docstring réelle des éléments répertoriés dans la docstring du module

Vous devez absolument documenter toutes les interfaces publiques, en utilisant des exemples si nécessaire. Pour les docstrings, sont utilisés les Google Python Style Docstrings Le parsing est réalisé par la napoleon sphinx extension. La documentation napoleon contient de bons exemples de docstrings correctement formatés.

Note

Vous pouvez utiliser toute directive Sphinx ou formatting rst si cela a du sens. Par exemple, une extension couramment utilisée est la directive jupyter-execute employée pour executer un bloc de code Jupyter et afficher à la fois le code et le résultat.

Intégrer la documentation¶

La documentation dans https://qiskit.org/documentation/ couvre l’intégralité du projet Qiskit. Terra n’est qu’une partie de ce projet. Les builds de cette documentation sont produits par le meta-package Qiskit https://github.com/Qiskit/qiskit. Lorsque les Commits sont rassemblés dans ce répertoire, les builds Sphinx sont chargés dans le site web qiskit.org. Ces builds Sphinx sont configurés pour pousser la documentation dans la version définie dans les meta-packages. Par exemple, si la version des meta-packages est toujours la 0.13.0, la documentation est issue de la version 0.10.0 de Terra. La documentation est poussée depuis la nouvelle version lorsque les meta-packages évoluent. Cela implique que les corrections faites à la documentation d’une API doivent être incluses dans une nouvelle version. Ces corrections sont des backports d’une version stable, conforme à la politique de branche stable (voir ci-dessous).

Pendant le processus de build, le contenu de docs/apidocs/ est copié dans une version partagée de doc/apidocs/ dans le répertoire du meta-package, en même temps que tous les autres éléments. Le contenu intégral de docs/apidocs se retrouvera donc à la racine de https://qiskit.org/documentation/apidoc/.

Traduction de la documentation¶

Les différentes traductions de la documentation Qiskit sont réalisées via l’outil Crowdin. Cette plateforme Web permet aux organisations de coordonner la traduction, facilite la collaboration et permet de ré-utiliser du matériel déjà traduit. Crowdin aide à la stabilité de la documentation traduite en assurant la mise à jour de phrases équivalentes présents dans différents fichiers.

Les demandes de traductions de Qiskit sont faites dans le répertoire Qiskit Translations. Pour participer à la traduction de Qiskit, suivez les étapes suivantes :

Ajoutez votre nom (ou ID) au fichier LOCALIZATION_CONTRIBUTORS .
Créez une pull request (PR) rassembler vos modifications. Suivez l’exemple suivant pour ouvrir une Pull Request.
Note
- Chaque contributeur doit créer sa propre PR et signer le CLA.
- Précisez la langue pour laquelle vous souhaitez contribuer dans le résumé de la PR.
- Si vous devez ouvrir un ticket pour cette demande, **ajoutez, dans la PR, le lien vers le ticket **.
Il vous sera demandé de signer le Qiskit Contributors License Agreement (CLA).
Un minimum de trois contributeurs par langue sont nécessaires pour ajouter de nouvelles langues, pour recevoir un support officiel de la part des administrateurs du projet de localisation.
Au sein du groupe de contributeurs, un responsable de la traduction doit être identifié pour servir de liaison avec les administrateurs du projet de localisation. Le responsable doit contacter: Yuri Kobayashi (yurik@jp.ibm.com) par courriel.
Dans le projet Qiskit-Docs <https://crowdin.com/project/qiskit-docs>` __ Crowdin, choisissez la langue à laquelle vous souhaitez contribuer.

Note

Comme il est précisé dans Qiskit in my language is Qiskit, nous souhaitons nous assurer que les langages ajoutés disposent d’un support fort de la communauté, avec des traducteurs, des correcteurs et des responsables de traduction. Si vous souhaitez devenir responsable de traduction (lead) ou si vous souhaitez vous joindre à une équipe de traduction, ouvrez un ticket Github pour initier une discussion et recruter de nouveaux participants.
Cliquez sur Join et copiez l’URL de votre PR dans la boite de dialogue apparaissant pour vous demander les raisons de votre contribution au projet Crowdin.

Les administrateurs du projet Crowdin examineront votre demande et vous donneront accès aussi rapidement que possible.

Traduire depuis la documentation source¶

Voici comment produire une version locale de la documentation dans votre clone du répertoire Qiskit/qiskit:

Clonez le dépôt Qiskit.

git clone https://github.com/Qiskit/qiskit.git

Un répertoire local appelé qiskit est créé automatiquement.
```
cd qiskit
```
Produisez la documentation associée à votre clone local de Qiskit/qiskit en exécutant la commande suivante dans une fenêtre Terminal.
```
tox -edocs
```
Si la commande tox n’est pas encore installée, exécutez :
```
pip install tox
```

En même temps que vous modifiez vos fichiers RST locaux, Vous pouvez mettre à jour les fichiers HTML correspondant en allant dans le répertoire /doc/ et en exécutant la commande :

tox -edocs

Les pages HTML ainsi produites sont automatiquement stockées dans le répertoire : /docs/_build/html/.

Installation à partir du code source¶

Installer des éléments depuis la source vous permet d’utiliser la version la plus à jour de Qiskit, plutôt que d’utiliser la version du dépôt de PyPI (Python Package Index). Ceci vous donnera la possibilité d’inspecter et d’étendre plus efficacement la dernière version du code Qiskit.

Lorsqu’une installation depuis la source est réalisée, par défaut, la version development``(correspondant à la branche ``master de git) sera utilisée, et non la version stable (qui contient le code des packages pip publiés). Puisque la version ``development``d’un composant inclut les toutes nouvelles modifications, il est nécessaire alors d’utiliser cette même version pour les autres éléments.

Note

Les packages Terra et Aer nécessitent un compilateur pour être construits depuis la source avant installation. Ignis, Aqua, et IBM Quantum Provider backend ne nécessitent pas de compilateur.

Installer depuis la source requière de respecter l’ordre d’installation suivant :

qiskit-terra
qiskit-aer
qiskit-ignis
qiskit-aqua
qiskit-ibmq-provider (if you want to connect to the IBM Quantum devices or online simulator)

Pour travailler avec plusieurs composants et éléments en même temps, suivez l’ordre ci-dessous pour chaque composant.

Note

Faites attention lorsque vous installez des packages (en raison des namespaces dans le packaging Python). Si vous souhaitez installer depuis la source, n’utilisez pas le meta-package qiskit. Suivez ce guide et utilisez un environnement de développement à part. Si vous choisissez de mélanger une installation existante avec votre propre installation, lisez https://github.com/pypa/sample-namespace-packages/blob/master/table.md pour découvrir les différentes combinaisons d’installations compatibles.

Installez l’environnement virtuel de développement¶

conda create -y -n QiskitDevenv python=3
conda activate QiskitDevenv

Installation de Terra depuis la Source¶

Cette installation nécessite un compilateur C++ supportant C++-11.

Compilateur pour Linux

En règle générale, le compilateur GCC est déjà installé.

Compilateur pour macOS

Si vous utilisez macOS, installez XCode et Clang. Depuis une fenêtre Terminal, vérifiez si XCode et Clang sont installés de cette façon.

clang --version

Installez XCode et Clang via les commandes suivantes.

xcode-select --install

Compilateur pour Windows

Sur Windows, le plus simple est d’installer le compilateur Visual C++ depuis Build Tools for Visual Studio 2017. Vous pouvez choisir Visual Studio version 2015 ou 2017, en prenant soin de valider les options pour installer le compilateur C++.

Une fois le compilateur installé, vous pouvez installer Qiskit Terra.

Clonez the répertoire Terra.

git clone https://github.com/Qiskit/qiskit-terra.git

Un répertoire local qiskit-terra est créé.
```
cd qiskit-terra
```
Installez les librairies Python nécessaires depuis le répertoire qiskit-terra.
```
pip install cython
```
Si vous souhaitez réaliser des tests ou faire du linting, installez les pré-requis Developeur.
```
pip install -r requirements-dev.txt
```
Installez ` ` qiskit-terra ` `.
```
pip install .
```

Pour une installation en mode Editable (les changements dans le code sont alors pris en compte sans besoin de réinstaller le projet), vous pouvez choisir cette commande :

pip install -e .

Une fois l’installation terminée, vous pouvez exécuter un premier exemple de code.

python examples/python/using_qiskit_terra_level_0.py

Note

Si vous n’installez aucun composant supplémentaire, qiskit-terra émettra un avertissement (RuntimeWarning) vous informant que qiskit-aer et qiskit-ibmq-provider ne sont pas installés. Ceci est fait car il est fréquent que les utilisateurs souhaitent utiliser des éléments additionnels, sans réaliser qu’ils ne sont pas installés, ou que les installations de Aer ou de IBM Quantum Provider ont échoué . Si vous souhaitez ne plus avoir ce warning, ajoutez:

import warnings
warnings.filterwarnings('ignore', category=RuntimeWarning,
                        module='qiskit')

avant chaque import qiskit dans votre code. Cela permettra de ne plus recevoir les warnings concernant qiskit-aer et qiskit-ibmq-provider, mais vous recevrez toujours les autres warnings venant de qiskit ou des autres packages.

Installation d’Aer à partir du code source¶

Cloner le dépôt Aer.

git clone https://github.com/Qiskit/qiskit-aer

Installez les Pré-requis .
```
pip install cmake scikit-build cython
```

Ensuite, les étapes d’installation de Aer dépendent du système d’exploitation que vous utilisez. Comme Aer est un programme C++ compilé avec une interface Python, il ya des dépendances non-Python pour construire le binaire Aer qui ne peut pas être installé universellement en fonction du système d’exploitation.

Construire et installer qiskit-aer directement

Si pip < 19.0.0 est installé et que votre environnement n’a pas besoin d’une génération personnalisée, exécutez:
```
cd qiskit-aer
pip install .
```
Cela compilera les binaires et installera Aer.

Alternativement, si vous avez installé un pip plus récent ou si vous avez des exigences personnalisées, vous pouvez construire une roue Python manuellement.
```
cd qiskit-aer
python ./setup.py bdist_wheel
```
Si vous avez besoin de définir une option personnalisée pendant la construction de la roue, reportez-vous à Options personnalisées lors de la construction de roues.

Après avoir construit la roue Python, elle sera stockée dans le répertoire dist/ dans le dépôt Aer. La version exacte dépendra
```
cd dist
pip install qiskit_aer-*.whl
```
Le nom exact du fichier roue en sortie dépend de la version courante d’Aer en cours de développement.

Options personnalisées lors de la construction de roues¶

Le système de construction Aer utilise ` scikit-build <https://scikit-build.readthedocs.io/en/latest/index.html>` __ pour exécuter la compilation lors de sa création avec l’interface Python. Il agit comme une interface pour » setuptools <https://setuptools.readthedocs.io/en/latest/>` __ pour appeler ` CMake <https://cmake.org/>` __ et compiler les binaires pour votre système local.

En raison de la complexité de la compilation des fichiers binaires, vous devrez peut-être passer des options à une certaine partie du processus de génération. Pour passer des variables, procédez comme suit:

python setup.py bdist_wheel [skbuild_opts] [-- [cmake_opts] [-- build_tool_opts]]

Où les éléments entre crochets ` [ ] ` sont optionnels et ` ` skbuild_opts ` `, ` ` cmake_opts ` `, ` ` build_tool_opts ` ` doivent être remplacés par des drapeaux de votre choix. Une liste des options *CMake * est disponible ici: https://cmake.org/cmake/help/v3.6/manual/cmake.1.html#options. Par exemple, vous pouvez exécuter quelque chose comme:

python setup.py bdist_wheel -- -- -j8

Ceci passe le drapeau -j8 ` au système de construction sous-jacent (qui dans ce cas est ` Automake <https://www.gnu.org/software/automake/> __), en lui disant que vous voulez construire en parallèle à l’aide de 8 processus.

Par exemple, un cas d’utilisation commun pour ces indicateurs sur linux est de spécifier une version spécifique du compilateur C++ à utiliser (normalement si la valeur par défaut est trop ancienne):

python setup.py bdist_wheel -- -DCMAKE_CXX_COMPILER=g++-7

qui dira à CMake d’utiliser la commande g++-7 au lieu de la commande g++ par défaut lors de la compilation de Aer.

Un autre cas d’utilisation courant pour ceci, en fonction de votre environnement, est que vous devrez peut-être spécifier le nom de votre plate-forme et désactiver la liaison statique.

python setup.py bdist_wheel --plat-name macosx-10.9-x86_64 \
-- -DSTATIC_LINKING=False -- -j8

Ici, --plat-name est un flag pour setuptools, pour spécifier le nom de la plate-forme à utiliser dans les métadonnées du paquet, -DSTATIC_LINKING est un flag pour utiliser CMake pour désactiver les liens statiques, et -j8 est un flag pour utiliser Automake pour utiliser 8 processus pour la compilation.

Voici une liste des options courantes en fonction de la plateforme:

Plateforme	Outil	Option	Cas d’utilisation
Tous	Automake	-j	Suivi d’un nombre, définit le nombre de processus à utiliser pour la compilation.
Linux	CMake	-DCMAKE_CXX_COMPILER	Utilisé pour spécifier un compilateur C++ spécifique; c’est souvent nécessaire si votre g++ par défaut l’est aussi.
OSX	outils d’installation	–plat-name	Utilisé pour spécifier le nom de la plateforme dans le package Python de sortie.
OSX	CMake	-DSTATIC_LINKING	Utilisé pour indiquer si un lien statique doit être utilisé ou non.

Note

Certaines de ces options ne sont pas spécifiques à une plateforme. Ces plateformes spécifiques sont répertoriées parce qu’elles sont couramment utilisées dans l’environnement. Pour plus d’informations, reportez-vous à la documentation de l’outil.

Installation d’Ignis à partir du code source¶

Cloner le dépôt Ignis.

git clone https://github.com/Qiskit/qiskit-ignis.git

Cloner le dépôt crée un répertoire local appelé qiskit-ignis.
```
cd qiskit-ignis
```
Si vous souhaitez exécuter des tests ou du linting (vérification de votre code), installez les outils développeur. Il n’est pas nécessaire d’installer ou d’utiliser le package qiskit-ignis lors de l’installation à partir du code source.
```
pip install -r requirements-dev.txt
```
Installez Ignis.
```
pip install .
```

Si vous souhaitez l’installer en mode modifiable, ce qui signifie que les modifications de programme apportées au projet ne nécessitent pas une réinstallation:

pip install -e .

Installation d’Aqua à partir du code source¶

Cloner le dépôt Aqua.

git clone https://github.com/Qiskit/qiskit-aqua.git

Le clonage du référentiel crée un répertoire local appelé ` ` qiskit-aqua ` `.
```
cd qiskit-aqua
```
Si vous souhaitez exécuter des tests ou du linting (vérification de votre code), installez les outils développeur. Il n’est pas nécessaire d’installer ou d’utiliser le package qiskit-aqua lors de l’installation à partir du code source.
```
pip install -r requirements-dev.txt
```
Installez Aqua.
```
pip install .
```

Si vous souhaitez l’installer en mode modifiable, ce qui signifie que les modifications de programme apportées au projet ne nécessitent pas une réinstallation:

pip install -e .

Installation d’IBM Quantum Provider à partir du code source¶

Cloner le dépôt qiskit-ibmq-provider .

git clone https://github.com/Qiskit/qiskit-ibmq-provider.git

Cloner le dépôt crée un répertoire local appelé qiskit-ibmq-provider.
```
cd qiskit-ibmq-provider
```
Si vous souhaitez exécuter des tests ou du linting (vérification de votre code), installez les outils développeur. Il n’est pas nécessaire d’installer ou d’utiliser le package qiskit-ibmq-provider lors de l’installation à partir du code source.
```
pip install -r requirements-dev.txt
```
Installez qiskit-ibmq-provider.
```
pip install .
```

Si vous souhaitez l’installer en mode modifiable, ce qui signifie que les modifications de programme apportées au projet ne nécessitent pas une réinstallation:

pip install -e .