Dateiformat

Wir wollten, dass das Dateiformat leicht als Diff zu lesen ist, wenn eine Änderung an der Lock-Datei überprüft wird. Daher und dank PEP 518 und pyproject.toml haben wir uns für das TOML-Dateiformat entschieden.

Sicher durch Design

Wenn man das Anforderungsdatei-Format als das Nächstliegende betrachtet, das wir als Lock-Dateistandard haben, gibt es einige Probleme mit dem Dateiformat in Bezug auf die Sicherheit. Erstens verlangt das Dateiformat einfach nicht, dass Sie die genaue Version eines Pakets angeben. Deshalb gibt es Tools wie pip-tools, die Benutzern von Anforderungsdateien helfen.

Zweitens müssen Sie opt-in sein, um anzugeben, welche Dateien installiert werden dürfen, indem Sie das Argument --hash für eine bestimmte Abhängigkeit verwenden. Dies ist auch mit pip-tools optional, da es das CLI-Argument --generate-hashes erfordert. Dies erfordert --require-hashes für pip, um sicherzustellen, dass keine Abhängigkeiten einen Hash zum Überprüfen fehlen.

Drittens, selbst wenn Sie kontrollieren, welche Dateien installiert werden dürfen, verhindert dies nicht die Installation anderer Pakete. Wenn eine Abhängigkeit nicht in der Anforderungsdatei aufgeführt ist, sucht pip gerne nach einer Datei, um diesen Bedarf zu decken. Sie müssen --no-deps als Argument für pip angeben, um unbeabsichtigte Abhängigkeitsauflösungen außerhalb der Anforderungsdatei zu verhindern.

Viertens erlaubt das Format die Installation einer Quellcodeverteilungsdatei (auch „sdist“ genannt). Von Natur aus erfordert die Installation eines sdists die Ausführung von beliebigem Python-Code, was bedeutet, dass keine Kontrolle darüber besteht, welche Dateien installiert werden dürfen. Nur durch Angabe von --only-binary :all: können Sie sicherstellen, dass pip für jedes Paket nur eine Wheel-Datei verwendet.

Zusammenfassend lässt sich sagen, dass ein Benutzer, damit eine Anforderungsdatei so sicher ist wie das, was vorgeschlagen wird, immer die folgenden Schritte ausführen sollte

1. Verwenden Sie pip-tools und seinen Befehl pip-compile --generate-hashes
2. Installieren Sie die Anforderungsdatei mit pip install --require-hashes --no-deps --only-binary :all:

Kritischerweise sind all diese Flags und sowohl die Spezifität als auch die Erschöpfung dessen, was installiert werden soll, was pip-tools bietet, optional für Anforderungsdateien.

Daher ist der in diesem PEP vorgeschlagene Ansatz von Grund auf sicher und bekämpft einige Supply-Chain-Angriffe. Hashes für Dateien, die zur Installation verwendet würden, sind erforderlich. Sie können nur von Wheels installieren, um eindeutig zu definieren, welche Dateien im Dateisystem platziert werden. Installer müssen zu einer deterministischen Installation aus einer Lock-Datei für eine bestimmte Plattform führen. All dies führt zu einer reproduzierbaren Installation, die Sie als vertrauenswürdig einstufen können (wenn Sie die Lock-Datei und deren Inhalt überprüft haben).

Plattformübergreifend

Verschiedene Projekte, die bereits eine Lock-Datei haben, wie z.B. PDM und Poetry, bieten eine Lock-Datei, die plattformübergreifend ist. Dies ermöglicht eine einzelne Lock-Datei, die auf mehreren Plattformen funktioniert und dennoch zu den exakt gleichen Top-Level-Anforderungen führt, die überall installiert werden, wobei die Installation auf jeder Plattform konsistent/eindeutig ist.

Warum das nützlich ist, sehen wir an einem Beispiel im Zusammenhang mit PyWeek (einem wochenlangen Spielentwicklungswettbewerb). Angenommen, Sie entwickeln unter Linux, während jemand, mit dem Sie eine Partnerschaft eingehen, macOS verwendet. Nehmen wir nun an, die Juroren verwenden Windows. Wie stellen Sie sicher, dass alle die gleichen Top-Level-Abhängigkeiten verwenden, während Sie gleichzeitig plattformspezifische Anforderungen zulassen (z.B. ein Paket benötigt unter Windows ein Hilfspaket)?

Mit einer plattformübergreifenden Lock-Datei können Sie sicherstellen, dass die wichtigsten Anforderungen plattformübergreifend konsistent erfüllt werden. Sie können dann auch sicherstellen, dass alle Benutzer auf derselben Plattform die gleiche reproduzierbare Installation erhalten.

Einfacher Installer

Die Trennung der Zuständigkeiten zwischen Locker und Installer ermöglicht es einem Installer, eine viel einfachere Aufgabe zu erfüllen. Somit ist es nicht nur einfacher, Installer zu schreiben, sondern es trägt auch dazu bei, dass Installer eindeutige, reproduzierbare Installationen korrekt erstellen.

Der Installer kann auch weniger Rechenleistung/Energie für die Installation aufwenden. Dies ist nicht nur für schnellere Installationen von Vorteil, sondern auch im Hinblick auf den Energieverbrauch, da von Installern erwartet wird, dass sie häufiger ausgeführt werden als Locker.

Dies hat zu einem Design geführt, bei dem der Locker mehr Arbeit im Voraus leisten muss, was den Installern zugutekommt. Es bedeutet auch, dass die Komplexität von Paketabhängigkeiten in Lock-Dateien einfacher und leichter verständlich ist, um Mehrdeutigkeiten zu vermeiden.

Details

Lock-Dateien MÜSSEN das TOML-Dateiformat verwenden. Dies verhindert nicht nur die Notwendigkeit eines weiteren Dateiformats im Python-Packaging-Ökosystem dank seiner Übernahme durch PEP 518 für pyproject.toml, sondern trägt auch dazu bei, Lock-Dateien besser lesbar zu machen.

Lock-Dateien MÜSSEN mit .pylock.toml enden. Der .toml-Teil unterscheidet das Format der Datei eindeutig und hilft Tools wie Code-Editoren, die Datei entsprechend zu unterstützen. Der .pylock-Teil unterscheidet die Datei von anderen TOML-Dateien, die der Benutzer hat, um die Logik für Tools zu erleichtern, Funktionalität speziell für Python-Lock-Dateien zu erstellen, anstatt für TOML-Dateien im Allgemeinen.

Die folgenden Abschnitte sind die Top-Level-Schlüssel des TOML-Dateidatenformats. Alle Felder, die nicht als erforderlich aufgeführt sind, gelten als optional.

Beispiel

version = "1.0"
created-at = 2021-10-19T22:33:45.520739+00:00

[tool]
# Tool-specific table.

[metadata]
requires = ["mousebender", "coveragepy[toml]"]
marker = "sys_platform == 'linux'"  # As an example for coverage.
requires-python = ">=3.7"

[[package.attrs."21.2.0"]]
filename = "attrs-21.2.0-py2.py3-none-any.whl"
hashes.sha256 = "149e90d6d8ac20db7a955ad60cf0e6881a3f20d37096140088356da6c716b0b1"
url = "https://files.pythonhosted.org/packages/20/a9/ba6f1cd1a1517ff022b35acd6a7e4246371dfab08b8e42b829b6d07913cc/attrs-21.2.0-py2.py3-none-any.whl"
requires-python = ">=2.7, !=3.0.*, !=3.1.*, !=3.2.*, !=3.3.*, !=3.4.*"

[[package.attrs."21.2.0"]]
# If attrs had another wheel file (e.g. that was platform-specific),
# it could be listed here.

[[package."coveragepy[toml]"."6.2.0"]]
filename = "coverage-6.2-cp310-cp310-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_12_x86_64.manylinux2010_x86_64.whl"
hashes.sha256 = "c7912d1526299cb04c88288e148c6c87c0df600eca76efd99d84396cfe00ef1d"
url = "https://files.pythonhosted.org/packages/da/64/468ca923e837285bd0b0a60bd9a287945d6b68e325705b66b368c07518b1/coverage-6.2-cp310-cp310-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_12_x86_64.manylinux2010_x86_64.whl"
requires-python = ">=3.6"
requires = ["tomli"]

[[package."coveragepy[toml]"."6.2.0"]]
filename = "coverage-6.2-cp310-cp310-musllinux_1_1_x86_64.whl "
hashes.sha256 = "276651978c94a8c5672ea60a2656e95a3cce2a3f31e9fb2d5ebd4c215d095840"
url = "https://files.pythonhosted.org/packages/17/d6/a29f2cccacf2315150c31d8685b4842a6e7609279939a478725219794355/coverage-6.2-cp310-cp310-musllinux_1_1_x86_64.whl"
requires-python = ">=3.6"
requires = ["tomli"]

# More wheel files for `coverage` could be listed for more
# extensive support (i.e. all Linux-based wheels).

[[package.mousebender."2.0.0"]]
filename = "mousebender-2.0.0-py3-none-any.whl"
hashes.sha256 = "a6f9adfbd17bfb0e6bb5de9a27083e01dfb86ed9c3861e04143d9fd6db373f7c"
url = "https://files.pythonhosted.org/packages/f4/b3/f6fdbff6395e9b77b5619160180489410fb2f42f41272994353e7ecf5bdf/mousebender-2.0.0-py3-none-any.whl"
requires-python = ">=3.6"
requires = ["attrs", "packaging"]

[[package.packaging."20.9"]]
filename = "packaging-20.9-py2.py3-none-any.whl"
hashes.blake-256 = "3e897ea760b4daa42653ece2380531c90f64788d979110a2ab51049d92f408af"
hashes.sha256 = "67714da7f7bc052e064859c05c595155bd1ee9f69f76557e21f051443c20947a"
url = "https://files.pythonhosted.org/packages/3e/89/7ea760b4daa42653ece2380531c90f64788d979110a2ab51049d92f408af/packaging-20.9-py2.py3-none-any.whl"
requires-python = ">=3.6"
requires = ["pyparsing"]

[[package.pyparsing."2.4.7"]]
filename = "pyparsing-2.4.7-py2.py3-none-any.whl"
hashes.sha256 = "ef9d7589ef3c200abe66653d3f1ab1033c3c419ae9b9bdb1240a85b024efc88b"
url = "https://files.pythonhosted.org/packages/8a/bb/488841f56197b13700afd5658fc279a2025a39e22449b7cf29864669b15d/pyparsing-2.4.7-py2.py3-none-any.whl"
direct = true  # For demonstration purposes.
requires-python = ">=2.6, !=3.0.*, !=3.1.*, !=3.2.*"

[[package.tomli."2.0.0"]]
filename = "tomli-2.0.0-py3-none-any.whl"
hashes.sha256 = "b5bde28da1fed24b9bd1d4d2b8cba62300bfb4ec9a6187a957e8ddb9434c5224"
url = "https://files.pythonhosted.org/packages/e2/9f/5e1557a57a7282f066351086e78f87289a3446c47b2cb5b8b2f614d8fe99/tomli-2.0.0-py3-none-any.whl"
requires-python = ">=3.7"

Erwartungen an Locker

Locker MÜSSEN Lock-Dateien erstellen, für die ein topologischer Sortierung der Pakete, die für die Installation auf der angegebenen Plattform in Frage kommen, einen Graphen ergibt, in dem nur eine Version eines jeden Pakets für die Installation in Frage kommt und für jedes Paket mindestens eine kompatible Datei zur Installation vorhanden ist. Dies führt zu einer Lock-Datei für jede unterstützte Plattform, bei der die einzige Entscheidung, die ein Installer treffen kann, darin besteht, welches "am besten passende" Wheel installiert wird (was weiter unten besprochen wird).

Von den Lockern wird erwartet, dass sie metadata.marker, metadata.tag und metadata.requires-python entsprechend sowie Umgebungskennzeichen, die über requires angegeben werden, und Python-Versionsanforderungen über requires-python verwenden, um dieses Ergebnis für Installer zu erzwingen. Anders ausgedrückt wird erwartet, dass die in der Lock-Datei verwendeten Informationen nicht "rein" aus der Eingabe des Lockers stammen, sondern stattdessen nach Bedarf geändert werden, um den Zielen des Lockers zu dienen.

Erwartungen an Installer

Der erwartete Algorithmus zur Auflösung dessen, was installiert werden soll, ist

1. Erstellen Sie einen Abhängigkeitsgraphen basierend auf den Daten in der Lock-Datei mit metadata.requires als Start-/Wurzelpunkt.
2. Eliminieren Sie alle Dateien, die von der angegebenen Plattform nicht unterstützt werden.
3. Eliminieren Sie alle irrelevanten Kanten zwischen Paketen basierend auf der Auswertung von Kennzeichen für requires.
4. Lösen Sie einen Fehler aus, wenn eine Paketversion vom Wurzelknoten des Abhängigkeitsgraphen aus noch erreichbar ist, aber keine kompatible Datei hat.
5. Überprüfen Sie, ob für alle verbleibenden Pakete nur noch eine zu installierende Version vorhanden ist, lösen Sie andernfalls einen Fehler aus.
6. Installieren Sie das am besten passende Wheel-Datei für jedes verbleibende Paket.

Installer MÜSSEN einem deterministischen Algorithmus folgen, um zu bestimmen, welches "am besten passende Wheel-Datei" ist. Eine einfache Lösung hierfür ist die Verwendung des packaging-Projekts und seines packaging.tags-Moduls, um die Priorität von Wheel-Dateien zu bestimmen.

Installer MÜSSEN die Installation in einer leeren Umgebung unterstützen. Installer KÖNNEN die Installation in einer Umgebung unterstützen, die bereits installierte Pakete enthält (und was auch immer damit verbunden ist, unterstützt zu werden).

Benutzerfreundlichkeit

Erstens könnte ein pip freeze-Äquivalent-Tool entwickelt werden, das eine Lock-Datei erstellt. Obwohl installierte Pakete allein nicht genügend Informationen liefern, um statisch eine Lock-Datei zu erstellen, könnte ein Benutzer lokale Verzeichnisse und Index-URLs angeben, um eine solche zu konstruieren. Dies würde dann zu Lock-Dateien führen, die strenger als eine Anforderungsdatei sind, indem die Lock-Datei auf die aktuelle Plattform beschränkt wird. Dies würde es den Leuten auch ermöglichen, zu sehen, ob ihre Umgebung reproduzierbar wäre.

Zweitens sollte ein eigenständiger Installer entwickelt werden. Da die Anforderungen an einen Installer viel einfacher sind als die, die pip bietet, sollte es angemessen sein, einen unabhängig entwickelten Installer zu haben.

Drittens könnte ein Tool entwickelt werden, um eine angepinnte Anforderungsdatei, wie sie von pip-tools ausgegeben wird, zu konvertieren. Ähnlich wie beim oben beschriebenen pip freeze-Äquivalent könnten einige Benutzereingaben erforderlich sein. Aber dieses Tool könnte als Übergangsschritt für jeden dienen, der eine geeignete Anforderungsdatei hat. Dies könnte auch als Test dienen, bevor pip-tools möglicherweise ein --lockfile-Flag zur Nutzung dieses PEPs erhält.

All dies könnte erforderlich sein, bevor das PEP vom bedingten Akzeptanz zum vollen Akzeptanz übergeht (und der Community die Chance gibt zu testen, ob dieses PEP potenziell nützlich ist).

Interoperabilität

An diesem Punkt wäre das Ziel, die Interoperabilität zwischen den Tools zu erhöhen.

Erstens würde pip ein Installer werden. Indem der am weitesten verbreitete Installer das Format unterstützt, können Leute auf der Locker-Seite innovativ sein, während sie wissen, dass die Leute über die notwendigen Werkzeuge verfügen, um eine Lock-Datei tatsächlich zu konsumieren.

Zweitens wird pip ein Locker. Wieder einmal würde Pips Reichweite das Format sehr schnell für die überwiegende Mehrheit der Python-Benutzer zugänglich machen.

Drittens unterstützt ein Projekt mit einem bereits vorhandenen Lock-File-Format mindestens den Export in das Lock-File-Format (z. B. PDM oder Pyflow). Dies würde zeigen, dass das Format die Bedürfnisse anderer Projekte erfüllt.

Akzeptanz

Mit den Werkzeugen, die in der gesamten Community verfügbar sind, würde die Akzeptanz dadurch gezeigt, dass auch diejenigen, die nicht ausschließlich an die Python-Community gebunden sind, das Dateiformat unterstützen, basierend auf dem, was sie für die Wünsche ihrer Nutzer halten.

Erstens, Werkzeuge, die mit Anforderungsdateien arbeiten, wie z. B. Code-Editoren, die eine gleichwertige Unterstützung für Lock-Dateien haben.

Zweitens würden auch Verbraucher von Anforderungsdateien wie Cloud-Anbieter Lock-Dateien akzeptieren.

Zu diesem Zeitpunkt wäre die PEP weit genug verbreitet, um in Bezug auf die allgemeine Akzeptanz auf dem gleichen Niveau wie Anforderungsdateien zu liegen, und möglicherweise mehr, wenn Projekte ihre eigenen Lock-Dateien zugunsten dieser PEP aufgegeben hätten.

Dateiformate außer TOML

JSON wurde kurzzeitig in Betracht gezogen, aber wegen

1. TOML, das bereits für pyproject.toml verwendet wird
2. TOML ist lesbarer
3. TOML führt zu besseren Diffs

wurde die Entscheidung getroffen, TOML zu verwenden. Es gab einige Bedenken hinsichtlich des Fehlens eines TOML-Parsers in der Standardbibliothek von Python, aber die meisten Paketierungswerkzeuge verwenden bereits einen TOML-Parser dank pyproject.toml, sodass dieses Problem kein Hindernis darstellte. Einige haben sich auch in der Vergangenheit gegen diese Bedenken gewandt, indem sie argumentierten, dass, wenn Paketierungswerkzeuge sich davor scheuen, Abhängigkeiten zu installieren und das Gefühl haben, kein Paket bündeln zu können, das Paketierungsökosystem weitaus größere Probleme zu beheben hat als die Notwendigkeit, von einem Drittanbieter-TOML-Parser abhängig zu sein.

Alternative Namensschemata

Die Angabe eines Verzeichnisses, in das Dateien installiert werden sollen, wurde in Erwägung gezogen, aber letztendlich verworfen, da die Leute diese Idee ablehnten.

Es wurde auch vorgeschlagen, keine spezielle Dateinamenerweiterung zu verwenden, aber es wurde entschieden, dass dies die Erkennbarkeit durch Werkzeuge zu sehr beeinträchtigen würde.

Unterstützung einer einzelnen Lock-Datei

Zu einem Zeitpunkt wurde die Idee in Erwägung gezogen, nur eine einzige Lock-Datei zu unterstützen, die alle möglichen Lock-Informationen enthielt. Aber es wurde schnell klar, dass der Versuch, ein Datenformat zu entwickeln, das sowohl ein Lock-File-Format, das mehrere Umgebungen unterstützt, als auch strenge Lock-Ergebnisse für reproduzierbare Builds umfassen könnte, sehr komplex und umständlich werden würde.

Die Idee, ein Verzeichnis von Lock-Dateien sowie eine einzelne Lock-Datei mit dem Namen pyproject-lock.toml zu unterstützen, wurde ebenfalls in Erwägung gezogen. Aber jede mögliche Einfachheit durch das Überspringen des Verzeichnisses im Falle einer einzelnen Lock-Datei schien unnötig. Der Versuch, geeignete Logiken dafür zu definieren, was die Datei pyproject-lock.toml sein sollte und was in pyproject-lock.d gehen sollte, schien unnötig kompliziert.

Verwendung einer flachen Liste anstelle eines Abhängigkeitsgraphen

Die erste Version dieser PEP schlug vor, dass die Lock-Datei kein Konzept eines Abhängigkeitsgraphen hat. Stattdessen würde die Lock-Datei genau auflisten, was für eine bestimmte Plattform installiert werden sollte, so dass Installierer keine Entscheidungen darüber treffen müssen, *was* installiert werden soll, sondern nur validieren, dass die Lock-Datei für die Zielplattform funktioniert.

Diese Idee wurde schließlich aufgrund der Anzahl von Kombinationen potenzieller PEP 508-Umgebungsmarker abgelehnt. Es wurde entschieden, dass der Versuch, von Lockern alle möglichen Kombinationen als einzelne Lock-Dateien generieren zu lassen, wenn ein Projekt plattformübergreifend sein soll, zu viel wäre.

Wheel-Tags im Dateinamen verwenden

Anstatt des Feldes metadata.tag gab es den Vorschlag, die Tags in den Dateinamen zu kodieren. Aber aufgrund der Hinzufügung des Feldes metadata.marker und was zu tun ist, wenn keine Tags benötigt wurden, wurde die Idee fallen gelassen.

Alternative Namen für requires

Einige andere Namen für das, was zu requires wurde, waren installs, needs und dependencies. Anfangs wählte diese PEP needs, nachdem sie einen Python-Anfänger gefragt hatte, welchen Begriff er bevorzugt. Aber basierend auf dem Feedback zu einem früheren Entwurf dieser PEP wurde requires als Begriff gewählt.

Akzeptanz von PEP 650

PEP 650 war ein früherer Versuch, dieses Problem anzugehen, indem eine API für Installer anstelle einer Standardisierung eines Lock-File-Formats (wie bei PEP 517) spezifiziert wurde. Die erste Reaktion auf PEP 650 könnte als mild/lauwarm betrachtet werden. Die Leute schienen sich konsequent darüber zu wundern, welche Werkzeuge welche Funktionalität zur Implementierung der PEP bereitstellen sollten. Außerdem incurred es potenziell mehr Overhead, da die Ausführung von Python-APIs für alle Aktionen im Zusammenhang mit der Paketierung erforderlich wäre.

Diese PEP wählt die Standardisierung auf ein Artefakt statt auf eine API (wie bei PEP 621). Dies würde mehr Werkzeugintegrationen ermöglichen, da die Notwendigkeit entfällt, speziell Python zu verwenden, um Dinge wie das Erstellen einer Lock-Datei, deren Aktualisierung oder sogar die Installation von in einer Lock-Datei aufgeführten Paketen durchzuführen. Es ermöglicht auch eine einfachere Introspektion, indem es die Details des Abhängigkeitsgraphen in einem lesbaren Format zwingt. Es ermöglicht auch einen einfacheren Wissensaustausch, indem standardisiert wird, was die Leute mehr wissen müssen (z. B. werden Tutorials zwischen Werkzeugen portabler, wenn es darum geht, das von ihnen erzeugte Artefakt zu verstehen). Es ist auch einfach der Ansatz, den andere Sprachgemeinschaften verfolgt haben und mit dem sie zufrieden zu sein scheinen.

Die Akzeptanz dieser PEP würde bedeuten, dass PEP 650 abgelehnt wird.

Anforderungen pro Paket statt pro Datei festlegen

Ein früherer Entwurf dieser PEP spezifizierte Abhängigkeiten auf Paketebene anstatt pro Datei. Während dies traditionell die Arbeitsweise von Paketierungssystemen war, spiegelte es tatsächlich nicht genau wider, wie Dinge spezifiziert werden. Als solches wurde diese PEP anschließend aktualisiert, um die Granularität widerzuspiegeln, auf der Abhängigkeiten wirklich spezifiziert werden können.

Festlegen, wo Locker Eingaben sammeln

Diese PEP spezifiziert nicht, wie ein Locker seine Eingaben erhält. Ein erster Vorschlag war, PEP 621 teilweise wiederzuverwenden, aber aufgrund von Meinungsverschiedenheiten darüber, wie flexibel die potenziellen Eingaben bei der Spezifikation von Dingen wie Indizes usw. sein sollten, wurde entschieden, dass dies am besten einer separaten PEP überlassen wird.

Quellcodeverteilungen und Quellcodebäume als opt-in, unterstütztes Dateiformat zulassen

Nach ausführlicher Diskussion wurde entschieden, dass diese PEP keine Quellcode-Distributionen (auch bekannt als sdists) oder Quellcode-Bäume als akzeptables Format für Code unterstützt. Die Einführung von sdists und Quellcode-Bäumen in diese PEP würde die Ziele der Reproduzierbarkeit und Sicherheit sofort aufheben, da Code zum Erstellen des sdist oder Quellcode-Baums ausgeführt werden müsste. Es würde auch die Komplexität für (zumindest) Installer erheblich erhöhen, da die dynamische Build-Natur von sdists und Quellcode-Bäumen bedeutet, dass der Installer die vollständige Auflösung aller Anforderungen, die sdists dynamisch produzieren, sowohl aus Sicht des Builds als auch der Installation bewältigen müsste.

Aufgrund all dessen wurde entschieden, dass es am besten ist, eine separate Diskussion über die Unterstützung von sdists und Quellcode-Bäumen zu führen, *nachdem* diese PEP akzeptiert/abgelehnt wurde. Da das vorgeschlagene Dateiformat mit Versionen versehen ist, ist die Einführung von sdists und Quellcode-Baum-Unterstützung in einer späteren PEP machbar.

Es sei jedoch darauf hingewiesen, dass diese PEP eine Out-of-Band-Lösung *nicht* stoppen wird, die in Verbindung mit dieser PEP entwickelt werden kann. Das Erstellen von Wheel-Dateien aus sdists und deren Auslieferung mit Code bei der Bereitstellung, damit sie in die Lock-Datei aufgenommen werden können, ist eine Option. Eine andere ist die Verwendung einer Anforderungsdatei *nur* für sdists und Quellcode-Bäume, und dann die Verlassung auf eine Lock-Datei für alle Wheels.