先日、Python パッケージの脆弱性データベースを調べていたときに、そこにあるパッケージ バージョンの一部が、標準に準拠していないため、簡単に解析できず、他のバージョン文字列と比較できないことに気づきました。 Python のバージョン管理 - 古い PEP 440 またはそれを置き換えるバージョン指定子の仕様。そこで私は、これがどれほど一般的なことなのか疑問に思いました。 Python パッケージ インデックス 実際に に有効なバージョンがあるパッケージはいくつありますか?

明白な答えは、「確認してみよう」です。そこで、新しい仮想環境を作成し、リクエストをダウンロードし、文字通り すべてのパッケージで使用されるすべてのバージョン文字列 を PyPI API にクエリするマルチプロセス スクリプトの作成を開始しました。すべてのコアで実行した場合でも数時間かかりましたが、終了までに 545,018 個のパッケージから 6,057,703 個を超えるバージョン文字列を取得し、きちんとした SQLite データベースに保存しました。 Kaggle で見つけることができます。

次は解析です。バージョン文字列のコンプライアンスを検証することを約束する 2 つのライブラリを見つけました:

• pepver: "PEP-440 バージョンの解析、解釈、および操作"
• parver: "parver を使用すると、PEP 440 バージョン番号の解析と操作が可能になります"

公平を期すために、これらは両方とも現在は置き換えられた PEP-440 に準拠していることに注意してください。そのため、特に非準拠としてマークされた文字列を見るときは、そのことを念頭に置いてください。

さらに数時間の集中的なマルチプロセッシングの後、これら 2 つのパッケージ (Kaggle にもあります) で文字列が正常に解析されたかどうかを示す 2 つのブール値列でデータベースを更新しました。

結果

調査結果の簡単な要約:

• 6,057,703 のバージョン文字列のうち、5,542 (0.09%) に欠陥が見つかりました;

• 545,018 個のパッケージのうち、1,285 (0.24%) に少なくとも 1 つの欠陥のあるバージョン文字列がありました。

全体的に、リポジトリの状態はかなり健全であるように見えます。両方のライブラリで間違っていることが検出されたバージョン文字列には、あらゆる種類があります。単純に非標準的な方法でサフィックスを使用するものもありますが、全体的にはセマンティック バージョニング パラダイムに従っていますが、他のものは単にコミット ハッシュまたは単語と数字の文字列です。

2 つのライブラリが一致しない場合の方が興味深いです。これらは、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

この場合、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

これらはすべて、開発サフィックスの後に区切り文字を付けて他の数字 (場合によっては日付) を使用する傾向があるという共通点があります。この場合、仕様では区切り文字が許可されていないため、これも確かに間違っています。したがって、やはりパーバーは正しいようです。

とにかく、これで私の当初の好奇心はほぼ満たされ、ほとんどの場合、バージョンを解析して比較する標準的な方法で十分であることがわかりました。非標準バージョンの中でも、偏差が最小限であるため、順序を識別するのは非常に簡単です。それでも、公式バージョン管理のすべての特徴を認識し、それらを信頼できる場合とできない場合を知ることは役に立ちます。