前幾天，當我研究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 後綴後使用其他數字（有時是日期），並帶有一些分隔符號。這確實也是錯誤的，因為在這種情況下規範不允許使用分隔符號。所以帕弗似乎又是對的。

無論如何，這幾乎滿足了我最初的好奇心，並使我放心，在絕大多數情況下，解析和比較版本的標準方法就足夠了。即使在非標準版本中，識別訂單通常也相當容易，因為偏差很小。儘管如此，了解官方版本控制的所有怪癖並了解我們何時可以或不能依賴它們還是很有用的。