Wie viele Python-Pakete sind korrekt versioniert?

Als ich neulich eine Datenbank mit Schwachstellen in Python-Paketen untersuchte, stellte ich fest, dass einige der darin enthaltenen Paketversionen nicht einfach analysiert und mit anderen Versionszeichenfolgen verglichen werden konnten, da sie nicht den Standards von entsprachen Python-Versionierung – entweder die alte PEP 440 oder die Version Specifiers-Spezifikation, die sie ersetzte. Also begann ich mich zu fragen, wie häufig das vorkam. Wie viele Pakete im Python-Paketindex haben tatsächlich gültige Versionen?

Die offensichtliche Antwort war: Schauen Sie nach. Also erstellte ich eine neue virtuelle Umgebung, lud Anfragen herunter und schrieb ein Multiprocessing-Skript, um die PyPI-API buchstäblich nach jeder von jedem Paket verwendeten Versionszeichenfolge abzufragen. Es dauerte ein paar Stunden, bis ich auf allen Kernen lief, aber am Ende hatte ich über 6.057.703 Versionszeichenfolgen aus 545.018 Paketen abgerufen, die in einer übersichtlichen SQLite-Datenbank gespeichert waren. Sie finden es auf Kaggle.

Als nächstes kam das Parsen. Ich habe zwei Bibliotheken gefunden, die versprochen haben, eine Versionszeichenfolge auf Konformität zu überprüfen:

• pepver: „Analyse, Interpretation und Manipulation der PEP-440-Version“
• parver: „Parver ermöglicht das Parsen und Bearbeiten von PEP 440-Versionsnummern“

Beachten Sie bitte, dass sich beide weiterhin an PEP-440 halten, das jetzt ersetzt wurde. Daher werde ich dies im Hinterkopf behalten, insbesondere wenn ich mir die als nicht konform markierten Saiten ansehe.

Nach weiteren Stunden intensiver Multiverarbeitung hatte ich meine Datenbank mit zwei booleschen Spalten aktualisiert, die angeben, ob die Zeichenfolgen mit diesen beiden Paketen erfolgreich analysiert wurden (auch auf Kaggle).

Die Ergebnisse

Für eine kurze Zusammenfassung meiner Ergebnisse:

• Von 6.057.703 Versionszeichenfolgen wurden 5.542 (0,09 %) als fehlerhaft befunden;

• Von 545.018 Paketen hatten 1.285 (0,24 %) mindestens eine fehlerhafte Versionszeichenfolge.

Der Zustand des Repositorys scheint also insgesamt recht gesund zu sein! Die von beiden Bibliotheken als falsch befundenen Versionszeichenfolgen sind unterschiedlicher Art. Einige verwenden die Suffixe einfach auf eine nicht standardmäßige Weise, folgen aber insgesamt dem semantischen Versionierungsparadigma, während andere lediglich Commit-Hashes oder Zeichenfolgen aus Wörtern und Zahlen verwenden.

Interessanter sind die Fälle, in denen die beiden Bibliotheken unterschiedlicher Meinung sind. Dies sind diejenigen, die Pepver nicht validiert, Parver jedoch:

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

In diesem Fall würde ich sagen, dass Pepver im Unrecht ist. Gemäß PEP440 und den aktuellen Versionierungsregeln ist r eine akzeptable Schreibweise für das Post-Release-Tag (standardisiert für „post“), und bei Buchstaben wird die Groß-/Kleinschreibung nicht beachtet. Somit normalisiert sich 0.0.2.R3 effektiv zu 0.0.2.post3 und ist völlig legal.

In der Zwischenzeit ist hier eine zufällige Auswahl von Versionen, die Pepver zugibt, Parver jedoch nicht:

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

Allen gemeinsam ist die Tendenz, nach dem Dev-Suffix andere Zahlen (gelegentlich Datumsangaben) mit einem Trennzeichen zu verwenden. Das ist in der Tat auch falsch, da die Spezifikation in diesem Fall das Trennzeichen nicht zulässt. Parver scheint also wieder recht zu haben.

Jedenfalls hat das meine ursprüngliche Neugier weitgehend befriedigt und mir die Gewissheit gegeben, dass in den allermeisten Fällen die Standardmethoden zum Parsen und Vergleichen von Versionen ausreichen werden. Selbst bei den nicht standardmäßigen Versionen ist es oft recht einfach, eine Reihenfolge zu identifizieren, da die Abweichungen minimal sind. Dennoch ist es nützlich, sich aller Eigenheiten der offiziellen Versionierung bewusst zu sein und zu wissen, wann wir uns darauf verlassen können und wann nicht.

Das obige ist der detaillierte Inhalt vonWie viele Python-Pakete sind korrekt versioniert?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!