El otro día, mientras buscaba en una base de datos de vulnerabilidades en paquetes de Python, me di cuenta de que algunas de las versiones de paquetes allí no se podían analizar y comparar fácilmente con otras cadenas de versión porque no cumplían con los estándares de Control de versiones de Python: ya sea el antiguo PEP 440 o la especificación de especificadores de versión que lo reemplazó. Entonces comencé a preguntarme qué tan común era esto. ¿Cuántos paquetes en el índice de paquetes de Python en realidad tienen versiones válidas?

La respuesta obvia fue: ve a comprobarlo. Así que creé un nuevo entorno virtual, descargué solicitudes y procedí a escribir un script de multiprocesamiento para consultar la API de PyPI literalmente cada cadena de versión utilizada por cada paquete . Me llevó algunas horas incluso ejecutarlo en todos los núcleos, pero al final había recuperado más de 6.057.703 cadenas de versión de 545.018 paquetes, almacenados en una ordenada base de datos SQLite. Puedes encontrarlo en Kaggle.

Luego vino el análisis. Encontré dos bibliotecas que prometían validar una cadena de versión para su cumplimiento:

• pepver: "Análisis, interpretación y manipulación de la versión PEP-440"
• parver: "parver permite analizar y manipular los números de versión de PEP 440"

Tenga en cuenta que, para ser justos, ambos todavía se adhieren a PEP-440, que ahora ha sido reemplazado, así que lo tendré en cuenta, especialmente cuando mire las cadenas marcadas como no conformes.

Después de un par de horas más de multiprocesamiento intenso, actualicé mi base de datos con dos columnas booleanas que indicaban si las cadenas se analizaron correctamente con estos dos paquetes (también en Kaggle).

Los resultados

Para un resumen rápido de mis hallazgos:

• de 6.057.703 cadenas de versión, 5.542 (0,09%) se encontraron defectuosas;

• de 545.018 paquetes, 1.285 (0,24%) tenían al menos una cadena de versión defectuosa.

Así que, en general, el estado del repositorio parece bastante saludable. Las cadenas de versión encontradas incorrectamente por ambas bibliotecas son de todo tipo. Algunos simplemente usan los sufijos de una manera no estándar, pero en general siguen el paradigma de versiones semánticas, mientras que otros simplemente confirman hashes o cadenas de palabras y números.

Los casos en los que las dos bibliotecas no están de acuerdo son más interesantes. Estos son los que pepver no valida pero parver si:

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

En este caso, diría que pepver está equivocado. Según PEP440 y las reglas de versiones actuales, r es una ortografía aceptable para la etiqueta posterior al lanzamiento (estandarizada para publicar) y las letras no distinguen entre mayúsculas y minúsculas. Entonces, efectivamente, 0.0.2.R3 se normaliza a 0.0.2.post3 y es perfectamente legal.

Mientras tanto, aquí hay una muestra aleatoria de versiones que pepver admite pero parver no:

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

Todos tienen en común la tendencia a utilizar otros números (ocasionalmente fechas) después del sufijo dev, con algún separador. De hecho, esto también es incorrecto, ya que la especificación no permite el separador en este caso. De nuevo Parver parece tener razón.

De todos modos, eso satisfizo mi curiosidad original y me aseguró que, para la gran mayoría de los casos, los métodos estándar de análisis y comparación de versiones serán suficientes. Incluso entre las versiones no estándar, suele ser bastante fácil identificar un pedido, ya que las desviaciones son mínimas. Aún así, es útil estar al tanto de todas las peculiaridades de la versión oficial y saber cuándo podemos o no confiar en ellas.