先日、Python パッケージの脆弱性データベースを調べていたところ、そこに含まれるパッケージ バージョンの一部が、標準に準拠していないため、簡単に解析できず、他のバージョン文字列と比較できないことに気づきました。 Python のバージョン管理 - 古い PEP 440 またはそれを置き換えるバージョン指定子の仕様のいずれか。そこで私は、これがどれほど一般的なことなのか疑問に思いました。 Python パッケージ インデックス実際に有効なバージョンがあるパッケージはいくつありますか?
明白な答えは、「行って確認してください」です。そこで、新しい仮想環境を作成し、リクエストをダウンロードし、文字通り すべてのパッケージで使用されるすべてのバージョン文字列 を PyPI API にクエリするためのマルチ処理スクリプトの作成に進みました。すべてのコアで実行した場合でも数時間かかりましたが、終了までに 545,018 個のパッケージから 6,057,703 個を超えるバージョン文字列を取得し、きちんとした SQLite データベースに保存しました。 Kaggle で見つけることができます。
次は解析です。バージョン文字列のコンプライアンスを検証することを約束する 2 つのライブラリを見つけました:
公平を期すために、これらは両方とも現在は置き換えられている 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
この場合、胡椒は間違っていると思います。 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
それらはすべて、開発サフィックスの後に区切り文字を付けて他の数字 (場合によっては日付) を使用する傾向があるという共通点があります。この場合、仕様では区切り文字が許可されていないため、これも確かに間違っています。したがって、やはりパーバーは正しいようです。
とにかく、これで私の当初の好奇心はほぼ満たされ、ほとんどの場合、バージョンを解析して比較する標準的な方法で十分であることがわかりました。非標準バージョンの中でも、偏差が最小限であるため、順序を識別するのは非常に簡単です。それでも、公式バージョン管理のすべての特徴を認識し、それらを信頼できる場合とできない場合を知ることは役に立ちます。
以上が正しくバージョン管理されている Python パッケージはいくつありますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。