L'autre jour, alors que j'examinais une base de données de vulnérabilités dans les packages Python, j'ai réalisé que certaines versions de packages ne pouvaient pas être facilement analysées et comparées à d'autres chaînes de versions car elles ne respectaient pas les normes de Gestion des versions Python - soit l'ancien PEP 440, soit la spécification Version Specifiers qui l'a remplacé. J’ai donc commencé à me demander à quel point c’était courant. Combien de packages sur l'index des packages Python réellement ont des versions valides ?

La réponse évidente était : allez vérifier. J'ai donc créé un nouvel environnement virtuel, téléchargé des requêtes et procédé à l'écriture d'un script multitraitement pour interroger l'API PyPI pour littéralement chaque chaîne de version utilisée par chaque package . Cela m'a pris quelques heures, même en fonctionnant sur tous les cœurs, mais à la fin, j'avais récupéré plus de 6 057 703 chaînes de version à partir de 545 018 packages, stockées dans une base de données SQLite soignée. Vous pouvez le trouver sur Kaggle.

Vient ensuite l'analyse. J'ai trouvé deux bibliothèques qui promettaient de valider une chaîne de version pour vérifier sa conformité :

• pepver : "Analyse, interprétation et manipulation de la version PEP-440"
• parver : "parver permet l'analyse et la manipulation des numéros de version PEP 440"

Notez que pour être honnête, ces deux éléments s'en tiennent toujours au PEP-440, qui a maintenant été remplacé, je garderai donc cela à l'esprit, en particulier lorsque je regarde les chaînes marquées comme non conformes.

Après encore quelques heures de multitraitement intense, j'avais mis à jour ma base de données avec deux colonnes booléennes indiquant si les chaînes étaient analysées avec succès avec ces deux packages (également sur Kaggle).

Les résultats

Pour un résumé rapide de mes découvertes :

• sur 6 057 703 chaînes de version, 5 542 (0,09 %) ont été jugées défectueuses ;

• sur 545 018 packages, 1 285 (0,24 %) avaient au moins une chaîne de version défectueuse.

Donc, dans l’ensemble, l’état du référentiel semble plutôt sain ! Les chaînes de version trouvées erronées par les deux bibliothèques sont de toutes sortes. Certains utilisent simplement les suffixes de manière non standard, mais suivent globalement le paradigme de gestion des versions sémantiques, tandis que d'autres ne font que valider des hachages ou des chaînes de mots et de nombres.

Les cas où les deux bibliothèques ne sont pas d'accord sont plus intéressants. Ce sont ceux que pepver ne valide pas mais que parver fait :

0.0.2.R
0.0.2.R3
0.0.2.R4
0.0.2.R5
0.0.2.R6
0.0.2.R7

Dans ce cas, je dirais que Pepper a tort. Conformément au PEP440 et aux règles de gestion de versions actuelles, r est une orthographe acceptable pour la balise post-version (normalisée pour publier) et les lettres ne sont pas sensibles à la casse. Donc, effectivement, 0.0.2.R3 se normalise en 0.0.2.post3 et est parfaitement légal.

En attendant, voici un échantillon aléatoire de versions que Pepver admet mais pas Parver :

0.0.1dev-20141025
1.5.0-dev-618
0.3.4.dev.20180830
1.15.0-dev-1552
1.4.0-dev-510
0.0.9.dev-20121012
0.2dev-20101203
0.3.4.dev.20180905
1.15.0-dev-1606
0.2.1dev-20110627
1.12.0-dev-1379
1.1.1-dev-275
1.3.1-dev-427

Ils ont tous en commun la tendance à utiliser d'autres nombres (parfois des dates) après le suffixe dev, avec un séparateur. C'est en effet également faux, car la spécification ne permet pas le séparateur dans ce cas. Encore une fois, Parver semble avoir raison.

Quoi qu'il en soit, cela a à peu près satisfait ma curiosité initiale et m'a rassuré sur le fait que pour la grande majorité des cas, les méthodes standard d'analyse et de comparaison des versions seront suffisantes. Même parmi les versions non standard, il est souvent assez facile d'identifier une commande, car les écarts sont minimes. Néanmoins, il est utile d'être conscient de toutes les bizarreries du versioning officiel, et de savoir quand nous pouvons ou non nous y fier.