Outro dia, enquanto eu estava pesquisando um banco de dados de vulnerabilidades em pacotes Python, percebi que algumas das versões de pacotes ali contidas não poderiam ser facilmente analisadas e comparadas com outras strings de versão porque elas não obedeciam aos padrões de Controle de versão do Python - o antigo PEP 440 ou a especificação dos especificadores de versão que o substituiu. Então comecei a me perguntar o quão comum isso era. Quantos pacotes no Índice de Pacotes Python realmente têm versões válidas?

A resposta óbvia foi: vá verificar. Então, criei um novo ambiente virtual, baixei solicitações e comecei a escrever um script de multiprocessamento para consultar a API PyPI literalmente cada string de versão usada por cada pacote . Levei algumas horas para executar todos os núcleos, mas no final eu havia recuperado mais de 6.057.703 strings de versão de 545.018 pacotes, armazenados em um banco de dados SQLite organizado. Você pode encontrá-lo no Kaggle.

Em seguida veio a análise. Encontrei duas bibliotecas que prometiam validar uma string de versão para conformidade:

• pepver: "Análise, interpretação e manipulação da versão PEP-440"
• parver: "parver permite análise e manipulação de números de versão PEP 440"

Observe que, para ser justo, ambos ainda seguem o PEP-440, que agora foi substituído, então terei isso em mente, especialmente ao observar as strings marcadas como não compatíveis.

Depois de mais algumas horas de multiprocessamento intenso, atualizei meu banco de dados com duas colunas booleanas indicando se as strings foram analisadas com sucesso com esses dois pacotes (também no Kaggle).

Os resultados

Para um rápido resumo das minhas descobertas:

• de 6.057.703 strings de versão, 5.542 (0,09%) foram consideradas defeituosas;

• de 545.018 pacotes, 1.285 (0,24%) tinham pelo menos uma string de versão com defeito.

Então, no geral, o estado do repositório parece bastante saudável! As strings de versão consideradas erradas por ambas as bibliotecas são de todos os tipos. Alguns simplesmente usam os sufixos de uma forma não padronizada, mas no geral seguem o paradigma de versionamento semântico, enquanto outros apenas confirmam hashes ou sequências de palavras e números.

Os casos em que as duas bibliotecas discordam são mais interessantes. Estes são aqueles que pepver não valida, mas parver sim:

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

Neste caso, eu diria que Pepver está errado. De acordo com o PEP440 e as regras de versão atuais, r é uma grafia aceitável para a tag pós-lançamento (padronizada para postar) e as letras não diferenciam maiúsculas de minúsculas. Então, efetivamente, 0.0.2.R3 normaliza para 0.0.2.post3 e é perfeitamente legal.

Enquanto isso, aqui está uma amostra aleatória de versões que pepver admite, mas parver não:

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 eles têm em comum a tendência de usar outros números (ocasionalmente datas) após o sufixo dev, com algum separador. Na verdade, isso também está errado, pois a especificação não permite o separador neste caso. Então, novamente, Parver parece certo.

De qualquer forma, isso satisfez bastante minha curiosidade original e me garantiu que, para a grande maioria dos casos, os métodos padrão de análise e comparação de versões serão suficientes. Mesmo entre as versões fora do padrão, muitas vezes é bastante fácil identificar um pedido, pois os desvios são mínimos. Ainda assim, é útil estar ciente de todas as peculiaridades do versionamento oficial e saber quando podemos ou não confiar neles.