Définition
Taper pip install requests suppose que quelque part, un fichier nommé requests existe déjà, prêt à être récupéré. PyPI est cet endroit précis : le dépôt public où les développeurs Python publient leurs bibliothèques, et que Python interroge par défaut à chaque installation. Sans lui, chaque projet devrait réécrire son propre code plutôt que de s'appuyer sur celui des autres.
PyPI, pour Python Package Index, ressemble moins à une boutique qu'à un catalogue de bibliothèque municipale : une fiche par projet, une archive téléchargeable par version, et rien de plus. Il ne s'exécute pas, ne s'installe pas et ne connaît rien de vos projets, il répond seulement aux demandes de téléchargement qu'on lui adresse.
Voici ce que cette réponse donne à voir, concrètement, quand la commande aboutit.
pip install requests
# Downloading requests-2.32.3-py3-none-any.whlLe nom de fichier affiché, requests-2.32.3-py3-none-any.whl, est celui que PyPI vient de servir. Mais c'est pip qui télécharge ce fichier et l'installe sur le disque : PyPI ne fait que le mettre à disposition. Cette distinction compte le jour où une installation échoue.
PyPI, pip et l'endroit où ça atterrit
Face à une installation qui échoue, le réflexe est d'incriminer PyPI. C'est rarement là que ça se joue. PyPI, pip et l'environnement virtuel désignent trois choses séparées, et confondre l'une avec l'autre fait chercher le problème au mauvais endroit.
Le tableau suivant sépare ce que fait chacun, pour savoir lequel interroger en premier.
| Nom | Rôle | Où il se trouve |
|---|---|---|
| PyPI | Héberge et distribue chaque package publié | En ligne |
pip | Télécharge, résout les dépendances, installe | Sur la machine |
| environnement virtuel | Reçoit les fichiers installés | Dans le projet |
Une installation qui échoue vient presque toujours de la deuxième ou de la troisième ligne, rarement de la première : le dépôt a répondu correctement, mais l'environnement actif au moment de la commande n'était pas celui qu'on croyait.
Ce qu'une fiche de projet permet de juger
Avant d'installer quoi que ce soit, une question se pose forcément : cette bibliothèque tient-elle la route, ou s'agit-il d'un projet abandonné qu'on va traîner comme dépendance morte ? La fiche PyPI d'un projet ne répond pas directement, mais elle donne quatre signaux qui, mis ensemble, permettent de trancher sans lire une ligne de code.
Voici ce que chacun de ces signaux révèle, une fois qu'on sait où regarder.
| Ce qu'on regarde | Ce que cela révèle |
|---|---|
| Date de la dernière version | Un projet suivi, ou abandonné depuis quatre ans |
| Nombre de versions | Une version unique signifie zéro correction publiée |
| Lien vers le code source | Absent, il n'y a rien à relire avant d'installer |
| Licence | Ce que l'usage commercial autorise réellement |
Rien de tout cela ne garantit la qualité du code. Mais l'ensemble dessine un niveau de sérieux qui se lit en trente secondes : une bibliothèque tenue à jour depuis huit ans ne se confond pas avec un projet déposé un soir et jamais retouché depuis.
N'importe qui peut publier, et le nom trompe
Publier sur PyPI ne demande ni compétence particulière ni relecture par qui que ce soit : créer un compte, envoyer une archive, et le paquet devient accessible au monde entier dans la minute qui suit. Cette ouverture explique la richesse du catalogue, mais aussi son unique danger sérieux.
Un paquet nommé à une lettre près d'une bibliothèque connue compte sur une faute de frappe pour s'installer à sa place. Recopier le nom depuis la documentation officielle, plutôt que de le retaper de mémoire, écarte l'essentiel du risque.
Le second piège ne relève pas de la sécurité, mais de la nomenclature : le nom qu'on installe n'est pas toujours celui qu'attend un import juste après. Le tableau ci-dessous montre les cas les plus fréquents.
| Nom à installer | Nom à importer |
|---|---|
| pillow | PIL |
| beautifulsoup4 | bs4 |
| scikit-learn | sklearn |
| python-dateutil | dateutil |
C'est l'origine du ModuleNotFoundError le plus déroutant de tous : celui qui survient juste après une installation qui vient pourtant de réussir sous les yeux du lecteur.
Quand PyPI ne sert à rien
Avant de taper une commande d'installation, une autre question mérite d'être posée : Python ne sait-il pas déjà faire ça tout seul ? Une bonne partie des besoins courants est déjà couverte par la bibliothèque standard, livrée avec l'interpréteur et donc absente de toute installation. Manipuler des chemins de fichiers avec pathlib, des dates avec datetime, du json ou des journaux d'exécution ne demande aucun téléchargement. Chercher un paquet pour cela revient à ajouter une dépendance à maintenir sans rien gagner en échange.
Deux autres situations sortent du dépôt public. Une entreprise peut héberger ses propres bibliothèques sur un dépôt interne, invisible depuis l'extérieur. Et une machine sans accès au réseau installe depuis des archives copiées à la main, en suivant la liste posée dans un requirements.txt.
Questions fréquentes
Faut-il un compte PyPI pour installer une bibliothèque ?
Non. La consultation et le téléchargement sont publics et anonymes, aucune inscription n'est demandée. Le compte ne devient nécessaire que pour publier un projet soi-même, et il exige alors une authentification à deux facteurs.
Comment savoir si un paquet est encore maintenu ?
La date de la dernière version donne la première réponse, le rythme des précédentes la confirme. Un projet publié tous les trois mois pendant cinq ans, puis silencieux depuis deux ans, est abandonné, quel que soit son nombre d'étoiles.
PyPI héberge-t-il aussi des outils, et pas seulement des bibliothèques ?
Oui. Les formateurs de code, les analyseurs statiques, les gestionnaires de projet comme poetry et les frameworks web y sont publiés exactement de la même façon. Un paquet peut fournir une commande à lancer, un module à importer, ou les deux à la fois.