На днях, просматривая базу данных уязвимостей в пакетах Python, я понял, что некоторые из версий пакетов нелегко проанализировать и сравнить со строками других версий, поскольку они не соответствуют стандартам Управление версиями Python — либо старый PEP 440, либо спецификация версий, которая его заменила. Поэтому я начал задаваться вопросом, насколько это распространено. Сколько пакетов в индексе пакетов Python на самом деле имеют действительные версии?

Очевидный ответ был: пойти проверить. Поэтому я создал новую виртуальную среду, загрузил запросы и приступил к написанию многопроцессорного сценария для запроса к API PyPI буквально каждой строки версии, используемой каждым пакетом . Даже работа на всех ядрах заняла у меня несколько часов, но к концу этого процесса я получил более 6 057 703 строк версий из 545 018 пакетов, хранящихся в аккуратной базе данных SQLite. Вы можете найти его на Kaggle.

Далее был разбор. Я нашел две библиотеки, которые обещали проверить строку версии на соответствие:

• pepver: "Разбор, интерпретация и манипулирование версией PEP-440"
• parver: "parver позволяет анализировать и манипулировать номерами версий PEP 440"

Обратите внимание, что, честно говоря, оба они по-прежнему придерживаются PEP-440, который теперь заменен, поэтому я буду иметь это в виду, особенно при просмотре строк, помеченных как не соответствующие требованиям.

После еще нескольких часов интенсивной многопроцессорной обработки я обновил свою базу данных двумя логическими столбцами, показывающими, успешно ли анализируются строки этими двумя пакетами (также на Kaggle).

Результаты

Краткий обзор моих выводов:

• из 6 057 703 строк версий 5 542 (0,09%) оказались дефектными;

• из 545 018 пакетов 1285 (0,24%) имели хотя бы одну дефектную строку версии.

В общем, состояние репозитория кажется вполне нормальным! Строки версий, которые обе библиотеки считают неправильными, бывают самых разных типов. Некоторые просто используют суффиксы нестандартным образом, но в целом следуют парадигме семантического управления версиями, в то время как другие просто фиксируют хэши или строки слов и чисел.

Случаи, когда две библиотеки расходятся во мнениях, более интересны. Это те, которые не проверяет Pepver, но проверяет Parver:

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

В данном случае я бы сказал, что перец неправ. Согласно PEP440 и текущим правилам управления версиями, r является приемлемым написанием тега после выпуска (стандартизированным для публикации), а буквы не чувствительны к регистру. Таким образом, 0.0.2.R3 нормализуется до 0.0.2.post3 и является совершенно законным.

Между тем, вот случайная выборка версий, которые Pepver допускает, а 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

Всех их объединяет тенденция использовать другие числа (иногда даты) после суффикса dev с некоторым разделителем. Это действительно тоже неправильно, поскольку в данном случае спецификация не допускает использования разделителя. Итак, парвер снова кажется прав.

В любом случае, это в значительной степени удовлетворило мое первоначальное любопытство и убедило меня в том, что для подавляющего большинства случаев стандартных методов анализа и сравнения версий будет достаточно. Даже среди нестандартных исполнений зачастую довольно легко определить порядок, поскольку отклонения минимальны. Тем не менее, полезно знать обо всех особенностях официальных версий и знать, когда мы можем или не можем на них полагаться.