Anbieter

Anbieter sind die Parteien (Organisation, Person, Community etc.), die einen Dienst oder ein Softwarewerkzeug liefern, das mit der Python-Paketierung und folglich mit Python-Paket-Installern interagiert. Zwei verschiedene Arten von Anbietern werden berücksichtigt.

Entwickler

Entwickler sind Teams, Personen oder Gemeinschaften, die Python-Paket-Installer und Python-Pakete programmieren und nutzen. Drei verschiedene Arten von Entwicklern werden berücksichtigt.

Aktualisierer & Paket-Infrastrukturanbieter

Paket-Aktualisierer und Paket-Infrastrukturen in CI/CD wie Dependabot, PyUP usw. unterstützen derzeit nur wenige Installer. Sie arbeiten, indem sie die Installer-spezifischen Abhängigkeitsdateien direkt (wie requirements.txt oder poetry.lock) mit relevanten Paketinformationen wie Upgrades, Downgrades oder neuen Hashes parsen und bearbeiten. Ähnlich wie bei Plattform- und IDE-Anbietern wollen die meisten dieser Anbieter keine N verschiedenen Python-Paket-Installer unterstützen, da dies die Unterstützung für N verschiedene Dateitypen erfordern würde.

Derzeit müssen diese Dienste/Bots die Unterstützung für jeden Paket-Installer einzeln implementieren. Unvermeidlich werden zuerst die beliebtesten Installer unterstützt, und weniger beliebte Tools werden oft nie unterstützt. Durch die Implementierung dieser Spezifikation können diese Dienste/Bots jeden (konformen) Installer unterstützen und Benutzern die Auswahl des Tools ihrer Wahl ermöglichen. Dies ermöglicht mehr Innovation in diesem Bereich, da Plattformen und IDEs nicht mehr gezwungen sind, vorzeitig einen "Gewinner" auszuwählen.

Open-Source-Community

Die Spezifikation von Installer-Anforderungen und die Übernahme dieser PEP reduziert die Reibung zwischen Python-Paket-Installern und den Workflows von Benutzern. Folglich reduziert sie die Reibung zwischen Python-Paket-Installern und 3rd-Party-Infrastrukturen/Technologien wie PaaS oder IDEs. Insgesamt ermöglicht sie einfachere Entwicklung, Bereitstellung und Wartung von Python-Projekten, da die Python-Paketinstallation einfacher und interoperabler wird.

Die Spezifikation von Anforderungen und die Erstellung einer Schnittstelle für Installer kann auch das Innovationstempo rund um Installer erhöhen. Dies würde es Installern ermöglichen, zu experimentieren und einzigartige Funktionalitäten hinzuzufügen, ohne dass der Rest des Ökosystems dasselbe tun muss. Die Unterstützung wird für einen neuen Installer unabhängig von der hinzugefügten Funktionalität und dem Format, in dem er Abhängigkeiten schreibt, einfacher und wahrscheinlicher, während der Zeit- und Ressourcenaufwand dafür reduziert wird.

[install-system]

Die Tabelle install-system wird verwendet, um install-system-relevante Daten und Informationen zu speichern. Es gibt mehrere obligatorische Schlüssel für diese Tabelle: requires und install-backend. Der Schlüssel requires enthält die Mindestanforderungen für die Ausführung des *Installer-Backends*, die vom *universellen Installer* installiert werden. Der Schlüssel install-backend enthält den Namen des Entry Points des Installer-Backends. Dies ermöglicht es dem *universellen Installer*, die Anforderungen für die Ausführung des *Installer-Backends* selbst zu installieren (nicht die Anforderungen, die das *Installer-Backend* selbst installieren wird) und das *Installer-Backend* aufzurufen.

Wenn einer der obligatorischen Schlüssel fehlt oder leer ist, SOLLTE der *universelle Installer* einen Fehler auslösen.

Alle Paketnamen, die mit dieser Schnittstelle interagieren, werden angenommen, dass sie dem Format der „Dependency specification for Python Software Packages“ von PEP 508 folgen.

Ein Beispiel für die Tabelle install-system

#pyproject.toml
[install-system]
#Eg : pipenv
requires = ["pipenv"]
install-backend = "pipenv.api:main"

[tool.poetry.dev-dependencies]
dependencies = "dev"

[tool.poetry.deploy]
dependencies = "deploy"

Installer-Schnittstelle

Die *Installer-Schnittstelle* enthält obligatorische und optionale Hooks. Konforme *Installer-Backends* MÜSSEN die obligatorischen Hooks implementieren und DÜRFEN die optionalen Hooks implementieren. Ein *universeller Installer* KANN jeden der *Installer-Backend*-Hooks selbst implementieren, um sowohl als *universeller Installer* als auch als *Installer-Backend* zu fungieren, dies ist jedoch nicht erforderlich.

Alle Hooks akzeptieren **kwargs beliebige Parameter, die ein *Installer-Backend* benötigt, die nicht bereits spezifiziert sind, was Abwärtskompatibilität ermöglicht. Wenn unerwartete Parameter an das *Installer-Backend* übergeben werden, sollte es diese ignorieren.

Die folgenden Informationen sind analog zum entsprechenden Abschnitt in PEP 517. Die Hooks können mit Schlüsselwortargumenten aufgerufen werden, daher sollten *Installer-Backends*, die sie implementieren, darauf achten, dass ihre Signaturen sowohl der Reihenfolge als auch den Namen der obigen Argumente entsprechen.

Alle Hooks KÖNNEN beliebige informative Texte nach stdout und stderr ausgeben. Sie DÜRFEN NICHT von stdin lesen, und der *universelle Installer* KANN stdin vor dem Aufruf der Hooks schließen.

Der *universelle Installer* kann stdout und/oder stderr vom Backend erfassen. Wenn das Backend erkennt, dass ein Ausgabestrom kein Terminal/eine Konsole ist (z. B. nicht sys.stdout.isatty()), SOLLTE es sicherstellen, dass alle Ausgaben, die es in diesen Strom schreibt, in UTF-8 kodiert sind. Der *universelle Installer* DARF NICHT fehlschlagen, wenn die erfasste Ausgabe kein gültiges UTF-8 ist, aber er KANN in diesem Fall nicht alle Informationen erhalten (z. B. kann er mit dem Ersetzungsfehlerhandler in Python dekodieren). Wenn der Ausgabestrom ein Terminal ist, ist das *Installer-Backend* für die genaue Darstellung seiner Ausgabe verantwortlich, wie bei jedem Programm, das in einem Terminal ausgeführt wird.

Wenn ein Hook eine Ausnahme auslöst oder den Prozess zum Abbruch bringt, deutet dies auf einen Fehler hin.

Obligatorische Hooks

def invoke_install(
    path: Union[str, bytes, PathLike[str]],
    *,
    dependency_group: str = None,
    **kwargs
) -> int:
    ...

Optionale Hooks

def invoke_uninstall(
    path: Union[str, bytes, PathLike[str]],
    *,
    dependency_group: str = None,
    **kwargs
) -> int:
    ...

def get_dependencies_to_install(
    path: Union[str, bytes, PathLike[str]],
    *,
    dependency_group: str = None,
    **kwargs
) -> Sequence[str]:
    ...

def get_dependency_groups(
    path: Union[str, bytes, PathLike[str]],
    **kwargs
) -> AbstractSet[str]:
    ...

def update_dependencies(
    path: Union[str, bytes, PathLike[str]],
    dependency_specifiers: Iterable[str],
    *,
    dependency_group=None,
    **kwargs
) -> int:
    ...

Eine standardisierte Lock-Datei

Eine standardisierte Lock-Datei würde viele der gleichen Probleme lösen, die auch die Spezifikation von Installer-Anforderungen löst. Zum Beispiel würde sie es PaaS/IaaS ermöglichen, nur einen Installer zu unterstützen, der die standardisierte Lock-Datei lesen könnte, unabhängig vom Installer, der sie erstellt hat. Das Problem mit einer standardisierten Lock-Datei sind die unterschiedlichen Bedürfnisse zwischen Python-Paket-Installern sowie ein grundlegendes Problem bei der Erstellung reproduzierbarer Umgebungen über die Lock-Datei (einer der Hauptvorteile).

Bedürfnisse und Informationen, die in Abhängigkeitsdateien zwischen Installern gespeichert werden, unterscheiden sich erheblich und sind von der Installer-Funktionalität abhängig. Zum Beispiel benötigt ein Python-Paket-Installer wie Poetry Informationen für alle Python-Versionen und Plattformen und berechnet entsprechende Hashes, während pip dies nicht tut. Zusätzlich könnte pip nicht garantieren, die gleiche Umgebung wiederherzustellen (exakt dieselben Abhängigkeiten zu installieren), da dies außerhalb seines Funktionsumfangs liegt. Dies macht eine standardisierte Lock-Datei schwerer zu implementieren und erscheint es sinnvoller, Lock-Dateien Tool-spezifisch zu gestalten.

Installer-Backends sollten die Erstellung von virtuellen Umgebungen unterstützen

Da *Installer-Backends* sehr wahrscheinlich ein Konzept von virtuellen Umgebungen und deren Installation haben, wurde kurz erwogen, ihnen auch die Unterstützung für die Erstellung virtueller Umgebungen zu geben. Letztendlich wurde dies jedoch als orthogonale Idee betrachtet.

Sollte das Argument dependency_group ein Iterable akzeptieren?

Dies würde die Angabe nicht überlappender Abhängigkeitsgruppen in einem einzigen Aufruf ermöglichen, z. B. die Gruppen „docs“ und „test“, die unabhängige Abhängigkeiten haben, die ein Entwickler jedoch möglicherweise gleichzeitig während der Entwicklung installieren möchte.

Wird das Installer-Backend In-Process ausgeführt?

Wenn das *Installer-Backend* In-Process ausgeführt wird, vereinfacht dies erheblich die Kenntnis, für welche Umgebung installiert wird/wird, da die laufende Python-Umgebung auf entsprechende Informationen abgefragt werden kann.

Die Ausführung außerhalb des Prozesses minimiert potenzielle Probleme mit Kollisionen zwischen der zu installierenden Umgebung und dem *Installer-Backend* (und möglicherweise dem *universellen Installer*).

Sicherstellen, dass die Ergebnisse der vorgeschlagenen Schnittstelle in andere Teile einfließen?

Z.B. können die Ergebnisse von get_dependencies_to_install() und get_dependency_groups() an invoke_install() übergeben werden. Dies würde Abweichungen zwischen den Ergebnissen verschiedener Teile der vorgeschlagenen Schnittstelle verhindern, macht aber mehr von der Schnittstelle obligatorisch statt optional.

Auslösen von Ausnahmen anstelle von Exit-Codes für Fehlerbedingungen

Es wurde vorgeschlagen, dass die API anstelle der Rückgabe eines Exit-Codes Ausnahmen auslösen sollte. Wenn Sie diese PEP als Hilfe zur Übersetzung aktueller Installer in *Installer-Backends* betrachten, dann ergibt die Verwendung von Exit-Codes Sinn. Es gibt auch den Punkt, dass die APIs keinen spezifischen Rückgabewert haben, sodass die Weitergabe eines Exit-Codes das, was die Funktionen zurückgeben, nicht beeinträchtigt.

Vergleichen Sie dies mit dem Auslösen von Ausnahmen im Fehlerfall. Dies könnte einen strukturierteren Ansatz zur Fehlerbehandlung bieten, obwohl zur Erfassung von Fehlern Ausnahmetypen als Teil der Schnittstelle spezifiziert werden müssten.