前几天，当我研究Python包中的漏洞数据库时，我意识到其中的一些包版本无法轻松解析并与其他版本字符串进行比较，因为它们不遵守Python 版本控制 - 旧的 PEP 440 或取代它的版本说明符规范。所以我开始想知道这种情况有多普遍。 Python 包索引上有多少包实际上具有有效版本？

显而易见的答案是：去检查。因此，我创建了一个新的虚拟环境，下载了请求，然后继续编写一个多处理脚本来查询 PyPI API，以获取每个包使用的每个版本字符串。即使在所有核心上运行，我也花了几个小时，但最终我从 545,018 个包中检索了超过 6,057,703 个版本字符串，这些字符串存储在一个整洁的 SQLite 数据库中。你可以在 Kaggle 上找到它。

接下来是解析。我发现两个库承诺验证版本字符串的合规性：

pepver:“PEP-440版本解析、解释和操作”
parver:“parver 允许解析和操作 PEP 440 版本号”

请注意，公平地说，这两个仍然坚持 PEP-440，现已被替换，所以我会记住这一点，特别是在查看标记为不合规的字符串时。

又经过几个小时的密集多重处理，我用两个布尔列更新了我的数据库，指示这两个包是否成功解析了字符串（也在 Kaggle 上）。

结果

快速总结我的发现：

• 在 6,057,703 个版本字符串中，发现有 5,542 个 (0.09%) 有缺陷；

• 在 545,018 个软件包中，1,285 个软件包 (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

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

在这种情况下，我想说 pepver 是错误的。根据 PEP440 和当前版本控制规则，r 是发布后标签（标准化为 post）的可接受拼写，并且字母不区分大小写。因此，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

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

它们的共同点是在 dev 后缀后使用其他数字（有时是日期），并带有一些分隔符。这确实也是错误的，因为在这种情况下规范不允许使用分隔符。所以帕弗似乎又是对的。

无论如何，这几乎满足了我最初的好奇心，并使我放心，在绝大多数情况下，解析和比较版本的标准方法就足够了。即使在非标准版本中，识别订单通常也相当容易，因为偏差很小。尽管如此，了解官方版本控制的所有怪癖并了解我们何时可以或不能依赖它们还是很有用的。