Following system colour scheme Selected dark colour scheme Selected light colour scheme

Python Enhancement Proposals

PEP 621 – Speicherung von Projektmetadaten in pyproject.toml

Autor:
Brett Cannon <brett at python.org>, Dustin Ingram <di at python.org>, Paul Ganssle <paul at ganssle.io>, Pradyun Gedam <pradyunsg at gmail.com>, Sébastien Eustace <sebastien at eustace.io>, Thomas Kluyver <thomas at kluyver.me.uk>, Tzu-ping Chung <uranusjr at gmail.com>
Discussions-To:
Discourse thread
Status:
Final
Typ:
Standards Track
Thema:
Packaging
Erstellt:
22-Jun-2020
Post-History:
22-Jun-2020, 18-Oct-2020, 24-Oct-2020, 31-Oct-2020
Resolution:
Discourse-Nachricht
Inhaltsverzeichnis

Wichtig

Dieses PEP ist ein historisches Dokument. Die aktuelle, kanonische Spezifikation, pyproject.toml-Spezifikation, wird auf der PyPA-Specs-Seite gepflegt.

×

Siehe den PyPA-Spezifikations-Update-Prozess, um Änderungen vorzuschlagen.

Zusammenfassung

Dieses PEP spezifiziert, wie die Kernmetadaten eines Projekts in einer pyproject.toml-Datei für die Nutzung durch packaging-bezogene Tools geschrieben werden.

Motivation

Die Hauptmotivationen für dieses PEP sind

  • Benutzer ermutigen, Kernmetadaten statisch für Geschwindigkeit, einfache Spezifikation, Eindeutigkeit und deterministische Verarbeitung durch Build-Backends anzugeben
  • Bereitstellen einer Tool-unabhängigen Möglichkeit zur Angabe von Metadaten für einfache Lernbarkeit und Übergänge zwischen Build-Backends
  • Ermöglichen von mehr Code-Sharing zwischen Build-Backends für die "langweiligen Teile" der Projektmetadaten

Um speziell auf die Motivation für statische Metadaten einzugehen: Dies war schon seit einiger Zeit ein allgemeines Ziel des Packaging-Ökosystems. Daher ist es wichtig, die Angabe von Metadaten im statischen Format zu erleichtern. Dies bedeutet auch, dass die Kosten für die Angabe von Daten als dynamisch erhöht werden können, da die Benutzer eher dazu neigen sollten, statische Metadaten anzugeben.

Das Erfordernis der Unterscheidung zwischen statischen und dynamischen Metadaten hilft auch bei der Klärung von Fällen, in denen Metadaten nicht angegeben sind. Wenn beliebige Metadaten *dynamisch* sein können, bedeutet dies, dass man nie weiß, ob das Fehlen von Metadaten beabsichtigt ist oder weil sie später bereitgestellt werden. Indem verlangt wird, dass dynamische Metadaten angegeben werden, wird die Absicht geklärt, wenn Metadaten nicht angegeben werden.

Dieses PEP versucht nicht, alle möglichen Metadaten zu standardisieren, die von einem Build-Backend benötigt werden, sondern nur die Metadaten, die von der Kernmetadaten-Spezifikation abgedeckt werden, welche in Projekten sehr verbreitet sind und davon profitieren würden, statisch und konsistent angegeben zu werden. Dies bedeutet, dass Build-Backends immer noch frei sind und mit Mustern experimentieren können, wie z. B. die Angabe von Dateien, die in ein Wheel aufgenommen werden sollen. Es gibt auch eine integrierte Ausweichmöglichkeit für Benutzer und Build-Backends, wenn sie sich entscheiden, teilweise aus diesem PEP auszusteigen (im Vergleich zum vollständigen Aussteigen aus diesem PEP, was ebenfalls möglich ist).

Dieses PEP versucht auch nicht, die zugrunde liegenden Kernmetadaten in irgendeiner Weise zu ändern. Solche Überlegungen sollten in einem separaten PEP behandelt werden, was zu Änderungen oder Ergänzungen dessen führen kann, was dieses PEP spezifiziert.

Begründung

Die Designrichtlinien, denen die Autoren dieses PEP folgten, waren:

  • Definiere eine Darstellung von möglichst vielen Kernmetadaten in pyproject.toml, wie es sinnvoll ist
  • Definiere die Metadaten statisch mit einer Ausweichmöglichkeit für diejenigen, die sie später dynamisch über ein Build-Backend definieren möchten
  • Verwende vertraute Namen, wo es sinnvoll ist, aber sei bereit, modernere Terminologie zu verwenden
  • Versuche, in einer TOML-Datei ergonomisch zu sein, anstatt wie Build-Backends Metadaten auf niedriger Ebene angeben, wenn es sinnvoll ist
  • Lerne von anderen Build-Backends im Packaging-Ökosystem, die TOML für ihre Metadaten verwendet haben
  • Versuche nicht, Dinge zu standardisieren, die auf niedrigerer Ebene keinen vordefinierten Standard haben
  • Wenn Metadaten mit diesem PEP angegeben werden, gelten sie als kanonisch

Spezifikation

Bei der Angabe von Projektmetadaten müssen sich Tools an die in diesem PEP angegebenen Metadaten halten und diese honorieren. Wenn Metadaten unsachgemäß angegeben werden, müssen Tools einen Fehler auslösen, um den Benutzer über seinen Fehler zu informieren.

Mit diesem PEP angegebene Daten gelten als kanonisch. Tools dürfen keine Daten entfernen, hinzufügen oder ändern, die statisch angegeben wurden. Nur wenn ein Feld als dynamic markiert ist, darf ein Tool einen "neuen" Wert bereitstellen.

Details

Tabellenname

Tools müssen Felder, die von diesem PEP definiert sind, in einer Tabelle namens [project] angeben. Keine Tools dürfen Felder zu dieser Tabelle hinzufügen, die nicht von diesem PEP oder nachfolgenden PEPs definiert sind. Für Tools, die ihre eigenen Einstellungen in pyproject.toml speichern möchten, können sie die [tool]-Tabelle gemäß PEP 518 verwenden. Das Fehlen einer [project]-Tabelle bedeutet implizit, dass das Build-Backend alle Felder dynamisch bereitstellt.

name

Der Name des Projekts.

Tools müssen Benutzer auffordern, dieses Feld statisch zu definieren.

Tools sollten diesen Namen normalisieren, wie in PEP 503 angegeben, sobald er für interne Konsistenz gelesen wird.

version

Die Version des Projekts, wie sie von PEP 440 unterstützt wird.

Benutzer sollten bevorzugen, bereits normalisierte Versionen anzugeben.

description

Die Zusammenfassung der Projektbeschreibung.

readme

Die vollständige Beschreibung des Projekts (d. h. die README).

Das Feld akzeptiert entweder einen String oder eine Tabelle. Wenn es ein String ist, ist es der relative Pfad zu einer Textdatei, die die vollständige Beschreibung enthält. Tools müssen davon ausgehen, dass die Dateikodierung UTF-8 ist. Wenn der Dateipfad mit einer Groß-/Kleinschreibung-unabhängigen .md-Erweiterung endet, müssen Tools davon ausgehen, dass der Content-Type text/markdown ist. Wenn der Dateipfad mit einer Groß-/Kleinschreibung-unabhängigen .rst-Erweiterung endet, müssen Tools davon ausgehen, dass der Content-Type text/x-rst ist. Wenn ein Tool mehr Erweiterungen erkennt als dieses PEP, darf es den Content-Type für den Benutzer ableiten, ohne dieses Feld als dynamic anzugeben. Für alle nicht erkannten Suffixe, wenn kein Content-Type angegeben wird, müssen Tools einen Fehler auslösen.

Das Feld readme kann auch eine Tabelle sein. Der Schlüssel file hat einen String-Wert, der einen relativen Pfad zu einer Datei darstellt, die die vollständige Beschreibung enthält. Der Schlüssel text hat einen String-Wert, der die vollständige Beschreibung ist. Diese Schlüssel sind gegenseitig ausschließend, daher müssen Tools einen Fehler auslösen, wenn die Metadaten beide Schlüssel angeben.

Eine in der readme-Tabelle angegebene Tabelle hat auch ein Feld content-type, das einen String mit dem Content-Type der vollständigen Beschreibung annimmt. Ein Tool muss einen Fehler auslösen, wenn die Metadaten dieses Feld nicht in der Tabelle angeben. Wenn die Metadaten nicht den Parameter charset angeben, wird UTF-8 angenommen. Tools dürfen andere Kodierungen unterstützen, wenn sie dies wünschen. Tools dürfen alternative Content-Types unterstützen, die sie in einen von den Kernmetadaten unterstützten Content-Type umwandeln können. Andernfalls müssen Tools bei nicht unterstützten Content-Types einen Fehler auslösen.

requires-python

Die Python-Versionsanforderungen des Projekts.

license

Die Tabelle kann einen von zwei Schlüsseln haben. Der Schlüssel file hat einen String-Wert, der ein relativer Dateipfad zur Datei ist, die die Lizenz für das Projekt enthält. Tools müssen davon ausgehen, dass die Dateikodierung UTF-8 ist. Der Schlüssel text hat einen String-Wert, der die Lizenz des Projekts ist und die Bedeutung des Feldes License aus den Kernmetadaten hat. Diese Schlüssel sind gegenseitig ausschließend, daher muss ein Tool einen Fehler auslösen, wenn die Metadaten beide Schlüssel angeben.

Ein praktischer String-Wert für den Schlüssel license wurde bewusst weggelassen, um einem zukünftigen PEP die Unterstützung für SPDX-Ausdrücke zu ermöglichen (die gleiche Logik gilt für jede Art von "Typ"-Feld, das angibt, welche Lizenz die file oder text darstellt).

authors/maintainers

  • Format: Array von Inline-Tabellen mit String-Schlüsseln und -Werten
  • Kernmetadaten: Author/Author-email/Maintainer/Maintainer-email (Link)
  • Synonyme
    • Flit: author/author-email/maintainer/maintainer-email (Link)
    • Poetry: authors/maintainers (Link)
    • Setuptools: author/author_email/maintainer/maintainer_email (Link)

Die Personen oder Organisationen, die als "Autoren" des Projekts gelten. Die genaue Bedeutung ist interpretationsfähig – sie kann die ursprünglichen oder Hauptautoren, aktuellen Maintainer oder Eigentümer des Pakets auflisten.

Das Feld "maintainers" ist ähnlich wie "authors" in Bezug auf die Interpretationsfähigkeit.

Diese Felder akzeptieren ein Array von Tabellen mit 2 Schlüsseln: name und email. Beide Werte müssen Strings sein. Der Wert name muss ein gültiger E-Mail-Name sein (d. h. alles, was als Name vor einer E-Mail in RFC 822 stehen kann) und darf keine Kommas enthalten. Der Wert email muss eine gültige E-Mail-Adresse sein. Beide Schlüssel sind optional.

Die Verwendung der Daten zur Füllung der Kernmetadaten erfolgt wie folgt:

  1. Wenn nur name angegeben wird, fließt der Wert in Author/Maintainer ein, je nach Fall.
  2. Wenn nur email angegeben wird, fließt der Wert in Author-email/Maintainer-email ein, je nach Fall.
  3. Wenn sowohl email als auch name angegeben werden, fließt der Wert in Author-email/Maintainer-email ein, je nach Fall, mit dem Format {name} <{email}> (mit entsprechender Anführungszeichensetzung, z. B. unter Verwendung von email.headerregistry.Address).
  4. Mehrere Werte sollten durch Kommas getrennt werden.

keywords

Die Schlüsselwörter für das Projekt.

classifiers

Trove-Klassifikatoren, die für das Projekt gelten.

urls

Eine Tabelle von URLs, bei der der Schlüssel das URL-Label und der Wert die URL selbst ist.

Entry points

Es gibt drei Tabellen, die sich auf Entry Points beziehen. Die Tabelle [project.scripts] entspricht der Gruppe console_scripts in der Entry points specification. Der Schlüssel der Tabelle ist der Name des Entry Points und der Wert ist die Objektreferenz.

Die Tabelle [project.gui-scripts] entspricht der Gruppe gui_scripts in der Entry points specification. Ihr Format ist dasselbe wie bei [project.scripts].

Die Tabelle [project.entry-points] ist eine Sammlung von Tabellen. Der Name jeder Untertabelle ist eine Entry Point-Gruppe. Die Schlüssel- und Wertsemantik ist dieselbe wie bei [project.scripts]. Benutzer dürfen keine verschachtelten Untertabellen erstellen, sondern müssen die Entry Point-Gruppen auf nur eine Ebene tief halten.

Build-Backends müssen einen Fehler auslösen, wenn die Metadaten eine Tabelle [project.entry-points.console_scripts] oder [project.entry-points.gui_scripts] definieren, da diese angesichts von [project.scripts] bzw. [project.gui-scripts] mehrdeutig wären.

dependencies/optional-dependencies

  • Format: Array von PEP 508-Strings (dependencies) und eine Tabelle mit Werten von Arrays von PEP 508-Strings (optional-dependencies)
  • Kernmetadaten: Requires-Dist und Provides-Extra (Link, Link)
  • Synonyme
    • Flit: requires für erforderliche Abhängigkeiten, requires-extra für optionale Abhängigkeiten (Link)
    • Poetry: [tool.poetry.dependencies] für Abhängigkeiten (sowohl erforderliche als auch für die Entwicklung), [tool.poetry.extras] für optionale Abhängigkeiten (Link)
    • Setuptools: install_requires für erforderliche Abhängigkeiten, extras_require für optionale Abhängigkeiten (Link)

Die (optionalen) Abhängigkeiten des Projekts.

Für dependencies handelt es sich um einen Schlüssel, dessen Wert eine Zeichenkette enthält. Jede Zeichenkette repräsentiert eine Abhängigkeit des Projekts und MUSS als gültige PEP 508-Zeichenkette formatiert sein. Jede Zeichenkette wird direkt einem Requires-Dist-Eintrag in den Core Metadata zugeordnet.

Für optional-dependencies handelt es sich um eine Tabelle, bei der jeder Schlüssel ein Extra angibt und dessen Wert ein Array von Zeichenketten ist. Die Zeichenketten der Arrays müssen gültige PEP 508-Zeichenketten sein. Die Schlüssel MÜSSEN gültige Werte für die Provides-Extra Core Metadata sein. Jeder Wert im Array wird somit zu einem entsprechenden Requires-Dist-Eintrag für die passende Provides-Extra-Metadaten.

dynamic

  • Format: Array von Zeichenketten
  • Core Metadata: N/A
  • Keine Synonyme

Gibt an, welche Felder, die in dieser PEP aufgeführt sind, absichtlich nicht spezifiziert wurden, damit ein anderes Werkzeug solche Metadaten dynamisch bereitstellen kann/wird. Dies grenzt klar ab, welche Metadaten absichtlich nicht spezifiziert sind und voraussichtlich nicht spezifiziert bleiben, im Gegensatz zu später über Werkzeuge bereitgestellten.

  • Ein Build-Back-End MUSS statisch spezifizierte Metadaten berücksichtigen (was bedeutet, dass die Metadaten das Feld nicht in dynamic aufgeführt haben).
  • Ein Build-Back-End MUSS einen Fehler auslösen, wenn die Metadaten den name in dynamic spezifizieren.
  • Wenn die Spezifikation der Core Metadata ein Feld als „Erforderlich“ aufführt, dann MÜSSEN die Metadaten das Feld statisch spezifizieren oder es in dynamic auflisten (Build-Back-Ends MÜSSEN andernfalls einen Fehler auslösen, d.h. es darf nicht möglich sein, dass ein erforderliches Feld irgendwie in der [project]-Tabelle nicht aufgeführt ist).
  • Wenn die Spezifikation der Core Metadata ein Feld als „Optional“ aufführt, KÖNNEN die Metadaten es in dynamic auflisten, wenn die Erwartung ist, dass ein Build-Back-End die Daten für das Feld später bereitstellen wird.
  • Build-Back-Ends MÜSSEN einen Fehler auslösen, wenn die Metadaten ein Feld sowohl statisch spezifizieren als auch in dynamic auflisten.
  • Wenn die Metadaten ein Feld nicht in dynamic auflisten, dann KANN ein Build-Back-End die erforderlichen Metadaten nicht im Namen des Benutzers ausfüllen (d.h. dynamic ist der einzige Weg, einem Werkzeug das Ausfüllen von Metadaten zu erlauben, und der Benutzer muss dem Ausfüllen zustimmen).
  • Build-Back-Ends MÜSSEN einen Fehler auslösen, wenn die Metadaten ein Feld in dynamic spezifizieren, aber das Build-Back-End die Daten dafür nicht bereitstellen konnte.

Beispiel

[project]
name = "spam"
version = "2020.0.0"
description = "Lovely Spam! Wonderful Spam!"
readme = "README.rst"
requires-python = ">=3.8"
license = {file = "LICENSE.txt"}
keywords = ["egg", "bacon", "sausage", "tomatoes", "Lobster Thermidor"]
authors = [
  {email = "hi@pradyunsg.me"},
  {name = "Tzu-ping Chung"}
]
maintainers = [
  {name = "Brett Cannon", email = "brett@python.org"}
]
classifiers = [
  "Development Status :: 4 - Beta",
  "Programming Language :: Python"
]

dependencies = [
  "httpx",
  "gidgethub[httpx]>4.0.0",
  "django>2.1; os_name != 'nt'",
  "django>2.0; os_name == 'nt'"
]

[project.optional-dependencies]
test = [
  "pytest < 5.0.0",
  "pytest-cov[all]"
]

[project.urls]
homepage = "https://example.com"
documentation = "https://readthedocs.org"
repository = "https://github.com"
changelog = "https://github.com/me/spam/blob/master/CHANGELOG.md"

[project.scripts]
spam-cli = "spam:main_cli"

[project.gui-scripts]
spam-gui = "spam:main_gui"

[project.entry-points."spam.magical"]
tomatoes = "spam:main_tomatoes"

Abwärtskompatibilität

Da dies eine neue Art der Spezifikation der Core Metadata eines Projekts darstellt und einen neuen Tabellennamen verwendet, der unter den reservierten Namensraum fällt, wie in PEP 518 beschrieben, gibt es keine Bedenken hinsichtlich der Abwärtskompatibilität.

Sicherheitsimplikationen

Es gibt keine direkten Sicherheitsbedenken, da diese PEP die statische Definition von Projektmetadaten abdeckt. Jegliche Sicherheitsprobleme würden daraus resultieren, wie Werkzeuge die Metadaten konsumieren und darauf reagieren.

Referenzimplementierung

Derzeit gibt es keine Proofs-of-Concept von einem Build-Back-End, das diese PEP implementiert.

Abgelehnte Ideen

Andere Tabellennamen

Alles unter [build-system]

Es gab Bedenken, dass die Verwendung dieses Tabellennamens die Verwirrung zwischen Build-Metadaten und Projektmetadaten verschärfen würde, z. B. durch die Verwendung von [build-system.metadata] als Tabelle.

[package]

Keine starke Unterstützung erhalten.

[metadata]

Der stärkste Kandidat nach [project], aber letztendlich wurde vereinbart, dass [project] für bestimmte Untertabellen besser lesbar ist, z. B. [project.urls].

Unterstützung für einen Metadaten-Provider

Ursprünglich gab es einen Vorschlag, eine Zwischenschicht zwischen den von dieser PEP statisch spezifizierten Metadaten und prepare_metadata_for_build_wheel(), wie in PEP 517 spezifiziert, einzufügen. Die Idee war, dass, wenn ein Projekt sich zwischen ein Build-Back-End und die Metadaten einfügen möchte, ein Hook dafür vorhanden wäre.

Letztendlich hielten die Autoren diese Idee für unnötig kompliziert und sie hätte die PEP von ihrem Designziel abgelenkt, Leute dazu zu bringen, Core Metadata so weit wie möglich statisch zu definieren.

Fordere einen normalisierten Projektnamen an

Obwohl es für Werkzeuge einfacher wäre, nur mit dem normalisierten Namen zu arbeiten, wie in PEP 503 spezifiziert, wurde die Idee letztendlich abgelehnt, da sie Projekten, die auf diese PEP umstellen, schaden würde.

Dateien angeben, die beim Erstellen eingeschlossen werden sollen

Die Autoren beschlossen während der Design-Diskussionen relativ schnell, dass sich diese PEP ausschließlich auf Projektmetadaten und nicht auf Build-Metadaten konzentrieren sollte. Daher ist die Spezifikation, welche Dateien in einer Quellcode-Distribution oder einem Wheel-File landen sollen, nicht im Geltungsbereich dieser PEP.

Benennen Sie die [project.urls]-Tabelle in [project.project-urls] um

Dieser Vorschlag kam dank der entsprechenden Core Metadata Project-Url. Aber sobald der allgemeine Tabellenname [project] gewählt wurde, legte die redundante Verwendung des Wortes „project“ nahe, dass der aktuelle, kürzere Name besser geeignet war.

Haben Sie ein separates url/home-page-Feld

Obwohl die Core Metadata dies unterstützt, erschien ein einzelnes Feld für die URL eines Projekts, während gleichzeitig eine vollständige Tabelle unterstützt wurde, als redundant und verwirrend.

Lassen Sie das Feld dynamic nur benötigte Felder angeben, die fehlen

Die Autoren erwogen die Idee, dass das Feld dynamic nur das Auflisten fehlender erforderlicher Felder verlangen und das Auflisten optionaler Felder optional machen würde. Letztendlich widersprach dies jedoch dem Designziel, so viel Information wie möglich statisch zu spezifizieren.

Unterschiedliche Strukturen für das Feld readme

Das Feld readme hatte ein vorgeschlagenes Feld readme_content_type, aber die Autoren hielten den Hybrid aus Zeichenkette/Tabelle für den häufigsten Fall praktischer, während sie den komplexeren Fall immer noch berücksichtigten. Dasselbe gilt für die Verwendung von long_description und einem entsprechenden Feld long_description_content_type.

Der Schlüssel file im Tabellenformat wurde ursprünglich als path vorgeschlagen, aber file entspricht dem file-Schlüssel von setuptools, und es gibt keinen starken Grund, einen über den anderen zu wählen.

Erlauben Sie dem Feld readme, text/plain implizit zu verwenden

Die Autoren erwogen die Zulassung von nicht spezifizierten Content-Types, die standardmäßig text/plain wären, entschieden sich aber, in diesem Fall explizit zu sein, um versehentlich falsche Renderings auf PyPI zu verhindern und Benutzer zu zwingen, ihre Absicht klar zu formulieren.

Andere Namen für dependencies/optional-dependencies

Die Autoren schlugen ursprünglich requires/extra-requires als Namen vor, entschieden sich aber für die aktuellen Namen, nachdem eine Umfrage unter anderen Packaging-Ökosystemen ergab, dass Python ein Ausreißer war.

  1. npm
  2. Rust
  3. Dart
  4. Swift
  5. Ruby

Die Normalisierung auf die aktuellen Namen hilft, Verwirrung für Personen zu minimieren, die aus anderen Ökosystemen kommen, ohne Terminologie zu verwenden, die für neue Programmierer unbedingt fremd ist. Sie vermeidet auch potenzielle Verwechslungen mit requires in der [build-system]-Tabelle, wie in PEP 518 spezifiziert.

Entfernen Sie maintainers, um es mit authors zu vereinheitlichen

Da der Unterschied zwischen den Feldern Authors und Maintainers in den Core Metadata nicht spezifiziert und mehrdeutig ist, schlug diese PEP ursprünglich vor, sie als ein einziges Feld authors zu vereinheitlichen. Andere Ökosysteme haben „author“ als zu verwendenden Begriff gewählt, daher war die Überlegung, Author in den Core Metadata als Ort für die Auflistung von Personen, die ein Projekt pflegen, zu standardisieren.

Letztendlich wurde jedoch die Entscheidung, sich an die Core Metadata zu halten, als wichtiger für die Akzeptanz dieser PEP erachtet, anstatt zu versuchen, eine neue Interpretation für einige der Core Metadata einzuführen.

Unterstützen Sie eine beliebige Tiefe von Tabellen für project.entry-points

Es gab Bedenken, dass die Beibehaltung von project.entry-points auf einer Tiefe von 1 für Untertabellen zu Verwirrung bei Benutzern führen würde, wenn sie einen Punktnamen verwenden und nicht an Tabellennamen mit Anführungszeichen gewöhnt sind (z. B. project.entry-points."spam.magical"). Aber die Unterstützung einer beliebigen Tiefe – z. B. project.entry-points.spam.magical – würde jede Form eines aufgebrochenen Tabellenformats in der Zukunft ausschließen. Es würde auch die Dinge für Build-Back-Ends verkomplizieren, da sie sicherstellen müssten, die gesamte Tabellenstruktur anstatt nur einer Ebene zu durchlaufen, und Fehler entsprechend den Wertetypen auslösen müssten.

Verwenden Sie strukturierte TOML-Dictionaries zur Angabe von Abhängigkeiten

Das Format für die Angabe der Abhängigkeiten eines Projekts war das am heißesten umstrittene Thema in Bezug auf das Datenformat. Es führte zur Erstellung sowohl von PEP 631 als auch von PEP 633, die das darstellen, was in dieser PEP und die Verwendung von TOML-Dictionaries extensiver ist, bzw. letzteres. Die Entscheidung zu diesen PEPs finden Sie unter https://discuss.python.org/t/how-to-specify-dependencies-pep-508-strings-or-a-table-in-toml/5243/38.

Die Autoren erwogen kurzzeitig die Unterstützung beider Formate, entschieden sich aber, dass dies zu Verwirrung führen würde, da die Leute sich mit zwei Formaten anstelle von nur einem vertraut machen müssten.

Fordern Sie Build-Backends auf, pyproject.toml beim Generieren eines sdist zu aktualisieren

Als diese PEP geschrieben wurde, benötigten sdists keine statischen, kanonischen Metadaten wie diese PEP. Damals wurde die Idee in Betracht gezogen, diese PEP als Mittel zu nutzen, um solche Metadaten in sdists zu bekommen. Letztendlich mochte die Idee, pyproject.toml zu aktualisieren, im Allgemeinen nicht, und so wurde die Idee zugunsten der separaten Standardisierung von Metadaten in sdists abgelehnt.

Erlauben Sie Tools, Daten hinzuzufügen/zu erweitern

In einer früheren Version dieser PEP durften Werkzeuge Daten für Felder erweitern. Beispielsweise konnten Build-Back-Ends die Versionsnummer nehmen und eine lokale Version hinzufügen, wenn sie das Wheel erstellten. Werkzeuge könnten auch weitere Trove-Klassifikatoren für Dinge wie die Lizenz oder unterstützte Python-Versionen hinzufügen.

Letztendlich wurde jedoch beschlossen, zunächst strenger zu sein und zu überlegen, wie statisch die Daten sein könnten, basierend auf der realen Nutzung.

Offene Fragen

Derzeit keine.

Quelle: https://github.com/python/peps/blob/main/peps/pep-0621.rst

Zuletzt geändert: 2025-02-01 08:55:40 GMT