Empfohlene, aber nicht erforderliche Abhängigkeiten

Paketbetreuer verwenden oft Extras, um optionale Abhängigkeiten zu deklarieren, die die Funktionalität oder Leistung eines Pakets erweitern. In einigen Fällen kann es schwierig sein zu bestimmen, welche Abhängigkeiten erforderlich sein sollten und welche als Extras kategorisiert werden sollten. Es muss ein Gleichgewicht zwischen den Bedürfnissen typischer Benutzer, die wahrscheinlich die meisten Funktionen standardmäßig verfügbar haben möchten, und Benutzern, die minimale Installationen ohne große, optionale Abhängigkeiten wünschen, gefunden werden. Eine Lösung mit der vorhandenen Python-Packaging-Infrastruktur besteht darin, dass Paketbetreuer ein Extra definieren, das beispielsweise recommended genannt wird und alle nicht-essenziellen, aber vorgeschlagenen Abhängigkeiten enthält. Benutzer werden dann angewiesen, das Paket mit package[recommended] zu installieren, während diejenigen, die mehr Kontrolle wünschen, package verwenden können. In der Praxis sind sich jedoch viele Benutzer der [recommended]-Syntax nicht bewusst, was die Last auf sie legt, dies für eine typische Installation zu wissen. Eine Möglichkeit, empfohlene Abhängigkeiten standardmäßig installieren zu lassen und gleichzeitig eine Möglichkeit für Benutzer zu bieten, eine minimalistischere Installation anzufordern, würde diesen Anwendungsfall erfüllen, und dieses PEP beschreibt eine Lösung dafür.

Beispiele für Pakete, die dieses Muster demonstrieren, indem sie Benutzer ermutigen, zusätzliche Abhängigkeiten standardmäßig einzubeziehen, sind:

• astropy: astropy[recommended]
• sunpy: sunpy[all]
• fastapi: fastapi[standard]

Pakete, die mehrere Backends oder Frontends unterstützen

Ein weiterer häufiger Anwendungsfall für die Verwendung von Extras ist die Definition verschiedener Backends oder Frontends und der Abhängigkeiten, die für jedes Backend oder Frontend installiert werden müssen. Ein Paket benötigt möglicherweise mindestens ein Backend oder Frontend, um funktionsfähig zu sein, ist aber möglicherweise flexibel, welches Backend oder Frontend dies ist. Konkrete Beispiele für solche Frontends oder Backends sind:

• Die Qt-Frontendbibliothek, die von PyQt5, PyQt6, PySide2 oder PySide6 bereitgestellt werden kann
• Backend-Datenbanken, wie z.B. MySQL, PostgreSQL, SQLite

Mit den aktuellen Packaging-Standards müssen Betreuer entweder eines der Backends oder Frontends anfordern oder Benutzer auffordern, immer Extras anzugeben, z.B. package[backend], und riskieren daher, dass Benutzer eine unbrauchbare Installation erhalten, wenn sie nur package installieren. Eine Möglichkeit, ein oder mehrere Standard-Backends oder -Frontends zu spezifizieren und eine Möglichkeit zur Überschreibung dieser Standardwerte bereitzustellen, würde eine deutlich bessere Benutzererfahrung bieten, und der in diesem PEP beschriebene Ansatz wird dies ermöglichen.

Beachten Sie, dass dieses PEP nicht darauf abzielt, das Problem der Verweigerung von widersprüchlichen oder inkompatiblen Extras zu lösen, z.B. wenn ein Paket genau ein Frontend- oder Backend-Paket benötigt. Derzeit gibt es keinen Mechanismus in der Python-Packaging-Infrastruktur, um widersprüchliche oder inkompatible Extras bei der Installation zu verweigern, und dieses PEP ändert daran nichts.

Beispiele für Pakete, die mindestens ein Backend oder Frontend zum Arbeiten benötigen und ein Standard-Extra zur Installation eines Backends oder Frontends empfehlen, sind:

• kivy: kivy[base]
• napari: napari[all]
• glueviz: glueviz[qt]

In allen drei Fällen führt die Installation des Pakets ohne Extras zu einer fehlerhaften Installation, und dies ist ein häufig gemeldetes Supportproblem für einige dieser Pakete.

Default-Extra Metadatenfeld

Ein neues, mehrfach verwendbares Metadatenfeld, Default-Extra, wird zu den Core Package Metadata hinzugefügt. Für dieses Feld muss jeder Eintrag eine Zeichenkette sein, die ein Extra angibt, das automatisch enthalten ist, wenn das Paket ohne explizit angegebene Extras installiert wird.

Nur Einträge, die bereits in einem Provides-Extra-Eintrag spezifiziert sind, können in einem Default-Extra-Eintrag verwendet werden.

Beispiele

Default-Extra: recommended
Default-Extra: backend1
Default-Extra: backend2
Default-Extra: backend3

Da dies ein neues Feld in den Core Package Metadata einführt, erfordert dies eine Erhöhung der Metadata-Version auf die nächste Minor-Version (derzeit 2.5).

Neuer Schlüssel in der Metadatentabelle [project]

Ein neuer Schlüssel wird der Tabelle [project] in den Projektmetadaten hinzugefügt, wie ursprünglich in PEP 621 definiert und jetzt in den PyPA-Spezifikationen definiert. Dieser Schlüssel wird default-optional-dependency-keys heißen und hat folgende Beschreibung:

• TOML-Typ: Array von Zeichenketten
• Entsprechendes Feld in den Core Metadata: Default-Extra

Jede Zeichenkette in default-optional-dependency-keys muss der Name eines Extras sein, das in optional-dependencies definiert ist, und jedes Extra in diesem Array wird in einen entsprechenden Default-Extra-Eintrag in den Core Package Metadata umgewandelt. Beispiele für gültige Verwendung, die die in der vorherigen Sektion dargestellten Beispiel-Default-Extra-Einträge erzeugen würden, sind:

[project]
default-optional-dependency-keys = [
    "recommended",
]

und

[project]
default-optional-dependency-keys = [
    "backend1",
    "backend2",
    "backend3"
]

Überschreiben von Standard-Extras

Wenn Extras in einer Abhängigkeitsspezifikation explizit angegeben werden, werden die Standard-Extras ignoriert. Andernfalls werden die Standard-Extras installiert.

Wenn beispielsweise ein Paket ein extra1 als Standard-Extra definiert, sowie ein nicht-standardmäßiges extra2-Extra, dann wird bei einer Installation durch den Benutzer mit

$ pip install package

die standardmäßige extra1-Abhängigkeit enthalten sein. Wenn der Benutzer stattdessen das Paket mit installiert

$ pip install package[extra2]

dann wird das extra2-Extra installiert, aber das Standard-extra1-Extra wird ignoriert.

Wenn dasselbe Paket mehrmals in einem Installationsbefehl oder einem Abhängigkeitsbaum angegeben wird, müssen die Standard-Extras installiert werden, wenn eine der Instanzen des Pakets ohne Extras angegeben wird. Zum Beispiel, wenn ein Paket spam installiert wird, wobei package mehrmals im Abhängigkeitsbaum vorkommt

spam
├── tomato
│   ├── package[extra2]
└── egg
    └── package

dann sollte das Standard-Extra installiert werden, da package mindestens einmal ohne angegebene Extras vorkommt.

Ein leerer Satz von Extras, wie z.B. package[], sollte so interpretiert werden, dass das Paket *ohne* jegliche Standard-Extras installiert werden soll (es sei denn, package kommt an anderer Stelle im Abhängigkeitsbaum vor, in welchem Fall das Standard-Extra wie oben erwähnt *installiert* würde). Dies würde eine universelle Möglichkeit bieten, eine minimale Installation eines Pakets zu erhalten.

Wir stellen auch fest, dass einige Werkzeuge wie pip derzeit nicht erkannte Extras ignorieren und eine Warnung an den Benutzer ausgeben, um anzuzeigen, dass das Extra nicht erkannt wurde, z.B.

$ pip install package[non-existent-extra]
WARNING: package 3.0.0 does not provide the extra 'non-existent-extra'
...

Für Werkzeuge, die sich so verhalten (anstatt einen Fehler auszugeben), sollten sie, wenn ein Extra in einer Abhängigkeitsspezifikation als ungültig erkannt wird, ignoriert werden. Wenn alle angegebenen Extras ungültig sind, sollte dies als äquivalent zu package[] (anstatt zu package) betrachtet werden und *keine* Standard-Extras installieren.

Schließlich weisen wir darauf hin (wie auch in Verlassen auf Werkzeuge zum Abwählen von Standard-Extras diskutiert), dass Paketinstallern erlaubt ist, ihre eigenen Optionen zu implementieren, um das oben genannte Verhalten zu steuern, z.B. eine Option, die Standard-Extras für einige oder alle Pakete deaktiviert, unabhängig davon, wo diese Pakete im Abhängigkeitsbaum erscheinen. Wenn solche werkzeugspezifischen Optionen implementiert werden, sollten Tool-Entwickler diese als Opt-in gestalten, und Benutzer sollten das obige PEP 771-Verhalten standardmäßig erleben.

Beispiele

In diesem Abschnitt betrachten wir die im Abschnitt Motivation beschriebenen Anwendungsfälle und wie diese nun durch die Verwendung der oben beschriebenen Spezifikation adressiert werden können.

[project]
default-optional-dependency-keys = [
    "recommended"
]

[project.optional-dependencies]
recommended = [
    "package1",
    "package2"
]

[project]
default-optional-dependency-keys = [
    "recommended"
]

[project.optional-dependencies]
recommended = [
    "scipy",
    "..."
]

$ pip install astropy

$ pip install astropy[]

[project]
default-optional-dependency-keys = [
    "backend1"
]

[project.optional-dependencies]
backend1 = [
    "package1",
    "package2"
]
backend2 = [
    "package3"
]

[project]
default-optional-dependency-keys = [
    "pyqt5"
]

[project.optional-dependencies]
pyqt5 = [
    "PyQt5",
    "..."
]
pyside2 = [
    "PySide2",
    "..."
]
pyqt6 = [
    "PyQt6",
    "..."
]
pyside6 = [
    "PySide6",
    "..."
]

$ pip install napari

$ pip install napari[pyside6]

[project]
default-optional-dependency-keys = [
    "recommended"
]

[project.optional-dependencies]
recommended = [
    "package1",
    "package2"
]
alternative = [
    "package3"
]
additional = [
    "package[recommended]",
    "package4"
]

[project]
default-optional-dependency-keys = [
    "recommended"
]

[project.optional-dependencies]
recommended = [
    "scipy",
    "..."
]
jupyter = [
    "astropy[recommended]",
    "ipywidgets",
    "..."
]

$ pip install astropy[jupyter]

$ pip install astropy[recommended, jupyter]

$ pip install package  # installs default backend and frontend
$ pip install package[]  # installs no backends or frontends
$ pip install package[backend1]  # installs backend1 and default frontend
$ pip install package[frontend2]  # installs frontend2 and default backend
$ pip install package[backend1, frontend2]  # installs backend1 and frontend2

$ pip install package  # installs default backend and frontend
$ pip install package[]  # installs no backends or frontends
$ pip install package[backend1, defaultfrontend]  # installs backend1 and default frontend
$ pip install package[defaultbackend, frontend2]  # installs frontend2 and default backend
$ pip install package[backend1, frontend2]  # installs backend1 and frontend2

Pakete, die keine Standard-Extras verwenden

Sobald die Unterstützung für dieses PEP in Werkzeugen des Packaging-Ökosystems hinzugefügt wurde, werden Pakete, die keine Standard-Extras verwenden, wie bisher funktionieren und es sollte keine Kompatibilitätsbrüche geben.

Pakete, die Standard-Extras verwenden

Sobald Pakete mit der Definition von Standard-Extras beginnen, werden diese Standards nur mit neueren Versionen von Packaging-Werkzeugen eingehalten, die dieses PEP implementieren, aber diese Pakete bleiben mit älteren Packaging-Werkzeugen installierbar – wobei der Hauptunterschied darin besteht, dass die Standard-Extras nicht automatisch installiert werden, wenn ältere Packaging-Werkzeuge verwendet werden.

Wie in Wie man das vermittelt beschrieben, müssen Paketautoren sorgfältig abwägen, wann und wie sie die Funktion der Standard-Extras übernehmen, abhängig von ihrer Benutzerbasis, da einige Aktionen (wie die Verschiebung einer erforderlichen Abhängigkeit zu einem Standard-Extra) wahrscheinlich zu Brüchen für Benutzer führen werden, wenn ein signifikanter Teil von ihnen noch ältere Paketinstallierer verwendet, die keine Standard-Extras unterstützen. In diesem Sinne sollten sich Paketautoren bewusst sein, dass diese Funktion, wenn sie auf bestimmte Weise verwendet wird, Rückwärtskompatibilitätsprobleme für Benutzer verursachen kann, und sie sind daher dafür verantwortlich, sicherzustellen, dass sie die Auswirkungen auf die Benutzer minimieren.

Verpackungsbezogene Werkzeuge

Der bedeutendste Aspekt der Rückwärtskompatibilität bezieht sich auf Annahmen, die Packaging-Werkzeuge über Extras machen – insbesondere ändert dieses PEP die Annahme, dass Extras nicht mehr ausschließlich additiv in Bezug auf das Hinzufügen von Abhängigkeiten zum Abhängigkeitsbaum sind, und die Angabe einiger Extras kann zu weniger installierten Abhängigkeiten führen.

Ein spezifisches Beispiel für eine Verhaltensänderung kann mit pip gesehen werden: Betrachten Sie ein Paket package, das eine erforderliche Abhängigkeit von numpy hat, und ein Standard-Extra namens recommended, das scipy enthält. Wenn ein Benutzer package[] installiert, werden nur package und numpy installiert. Wenn ein Benutzer dann

$ pip freeze > requirements.txt

dann wird requirements.txt z.B. enthalten:

package==1.0.2
numpy==2.1.0

Wenn der Benutzer jedoch dann die Anforderungen aus dieser Datei mit installiert

$ pip install -r requirements.txt

dann wird pip package (das das Standard-Extra enthält) sowie numpy installieren, so dass die endgültige Umgebung scipy enthalten wird. Eine Lösung in diesem speziellen Fall ist, dass der Benutzer --no-deps an pip install übergibt, um die Auflösung des Abhängigkeitsbaums zu vermeiden, aber der Punkt hier ist, zu veranschaulichen, dass es zu Verhaltensänderungen in Packaging-Werkzeugen aufgrund der Änderung der Annahme über die Auswirkungen kommen kann, die ein Extra haben kann.

Es ist erwähnenswert, dass das kürzlich akzeptierte PEP 751 ein neues Dateiformat definiert, das Alternativen wie die Ausgabe von pip freeze und andere Werkzeuge in Zukunft ersetzen soll. Das neue Dateiformat ist so konzipiert, dass die Pakete in der Datei *ohne* Auflösung von Abhängigkeiten installiert werden, was bedeutet, dass es vollständig kompatibel mit den in diesem PEP spezifizierten Standard-Extras sein wird und das Problem mit pip freeze/pip install -r vermeiden wird, wie oben erwähnt.

Paketendbenutzer

Paketbenutzern sollten klare Installationsanweisungen zur Verfügung gestellt werden, die zeigen, welche Extras für Pakete verfügbar sind und wie sie funktionieren, z.B. indem erklärt wird, dass standardmäßig einige empfohlene Abhängigkeiten oder ein bestimmtes Frontend oder Backend installiert werden, und wie man sich davon abmeldet oder Standardeinstellungen überschreibt, je nachdem, was verfügbar ist.

Paketersteller

Obwohl der Mechanismus zur Definition von Extras und die damit verbundene Regel, wann er verwendet werden soll, klar sind, müssen Paketautoren mehrere Punkte sorgfältig prüfen, bevor sie diese Funktionalität in ihren Paketen übernehmen, um unbeabsichtigte Rückwärtskompatibilitätsbrüche zu vermeiden.

$ pip install package  # this installs package[A]
$ pip install package[B]

package1
└── package2
    └── package1

$ pip install package1[]

package1
└── package2
    └── package1[]

Betreuer von Paket-Repositories

Die Auswirkungen auf Einzelpersonen, die Python-Bibliotheken für verschiedene Distributionen neu verpacken, wie z. B. conda, Homebrew, Linux-Paketinstallationsprogramme (wie apt und yum) usw., müssen berücksichtigt werden. Nicht alle Paketdistributionen verfügen über Mechanismen, die dem beschriebenen Ansatz entsprechen würden. Tatsächlich haben einige Distributionen wie conda nicht einmal das Konzept von Extras.

Hier sind zwei Fälle zu berücksichtigen

• In Fällen, in denen die Neuverpackung von Hand erfolgt, z. B. für eine Reihe von conda-forge-Rezepten, und insbesondere, wenn es kein Äquivalent zu Extras gibt, sollte die Einführung von Standard-Extras keinen großen Einfluss haben, da manuelle Entscheidungen bereits getroffen werden müssen, welche Abhängigkeiten einzuschließen sind (zum Beispiel enthält das conda-forge-Rezept für das Paket astropy, das im Abschnitt Motivation erwähnt wird, standardmäßig alle recommended Abhängigkeiten, da Benutzer sie anderweitig nicht explizit anfordern können).
• In Fällen, in denen die Neuverpackung automatisiert erfolgt, müssen die Distributoren sorgfältig überlegen, wie mit Standard-Extras umzugehen ist, und dies kann eine nicht unerhebliche Menge an Arbeit und Diskussion bedeuten.

Es ist für einen PEP wie diesen unmöglich, jeden der verschiedenen Paketdistributionen erschöpfend zu berücksichtigen. Letztendlich sollten Standard-Extras jedoch als die Art und Weise verstanden werden, wie Paketautoren möchten, dass ihr Paket für die Mehrheit der Benutzer installiert wird, und dies sollte Entscheidungen darüber informieren, wie Standard-Extras behandelt werden sollen, sei es manuell oder automatisch.

Verwendung eines Meta-Pakets für empfohlene Installationen

Unter Verwendung bestehender Packaging-Tools und -Infrastruktur können Paketbetreuer, die für einige Benutzer eine minimale Installation und für normale Benutzer eine standardmäßige nicht-minimale Installation (z. B. mit empfohlenen Abhängigkeiten oder einem Standard-Backend) bereitstellen möchten, dies technisch bereits erreichen, wenn sie bereit sind, zwei Pakete anstelle von einem zu verteilen – z. B. package-core, das das Hauptpaket mit minimalen Abhängigkeiten wäre, und package, das ein Metapaket wäre, das von package-core mit optionalen Abhängigkeiten abhängen würde.

Nehmen wir noch einmal ein konkretes Beispiel aus dem Abschnitt Motivation. Das Paket astropy definiert ein recommended Extra, dessen Installation den Benutzern derzeit in den Standardinstallationsanweisungen empfohlen wird. Im Prinzip könnte man das bestehende Paket astropy in z. B. astropy-core umbenennen und dann ein neues Paket astropy erstellen, das ein Metapaket wäre, das den folgenden Abhängigkeitsabschnitt enthält:

dependencies = [
    "astropy-core[recommended]"
]

Da Benutzer Versionen oder Versionsbeschränkungen für das astropy Meta-Paket festlegen möchten (z. B. astropy>5.0), müsste das Meta-Paket denselben Versionen wie das Kernpaket folgen und strenge Pinning im Abhängigkeitsabschnitt verwenden, z. B.:

version = "7.1.0"
dependencies = [
    "astropy-core[recommended]==7.1.0"
]

Diese Idee mag ansprechend erscheinen, da sie technisch bereits machbar ist. In der Praxis haben sich jedoch viele Projekte aus einer Reihe von Gründen dagegen entschieden, die wir uns nun ansehen. Einige davon sind möglicherweise nicht auf zukünftige neue Projekte anwendbar, aber einige davon gelten für alle Projekte, alte und neue.

$ pip uninstall package

Syntax zum Abwählen von Extras

Einer der Hauptkonkurrenzansätze war wie folgt: Anstatt Standard-Extras auszuwählen, wenn explizit Extras bereitgestellt wurden, müssten Standard-Extras explizit abgewählt werden.

In diesem Bild würde eine neue Syntax zum Abwählen von Extras als Erweiterung der in PEP 508 definierten Mini-Sprache eingeführt. Wenn ein Paket Standard-Extras definierte, könnten Benutzer diese Standardeinstellungen durch Verwenden eines Minuszeichens (-) vor dem Extra-Namen abwählen. Die vorgeschlagene Syntaxaktualisierung wäre wie folgt:

extras_list   = (-)?identifier (wsp* ',' wsp* (-)?identifier)*

Gültige Beispiele für diese neue Syntax wären z. B.

• package[-recommended]
• package[-backend1, backend2]
• package[pdf, -svg]

Es gibt jedoch zwei Hauptprobleme bei diesem Ansatz

• Man müsste eine Reihe von Regeln definieren, wie Eckfälle zu interpretieren sind, z. B. wenn ein Extra und seine negierte Version beide in derselben Abhängigkeitsspezifikation vorhanden sind (z. B. package[pdf, -pdf]) oder wenn ein Abhängigkeitsbaum sowohl package[pdf] als auch package[-pdf] enthält, und die Regeln wären für Benutzer nicht intuitiv.
• Noch kritischer ist, dass dies neue Syntax in die Abhängigkeitsspezifikation einführen würde, was bedeutet, dass, wenn ein Paket eine Abhängigkeit mit der neuen Syntax definierte, es und jedes andere Paket, das davon abhängt, nicht mehr von bestehenden Packaging-Tools installiert werden könnten, was einen erheblichen Rückwärtskompatibilitätsbruch darstellen würde.

Aus diesen Gründen wurde diese Alternative nicht in den endgültigen Vorschlag aufgenommen.

Hinzufügen eines speziellen Eintrags in extras_require

Eine mögliche Lösung, die als Alternative zur Einführung des neuen Metadatenfeldes Default-Extra untersucht wurde, wäre die Verwendung eines Extras mit einem „speziellen“ Namen.

Ein Beispiel wäre die Verwendung eines leeren Strings

Provides-Extra:
Requires-Dist: numpy ; extra == ''

Die Idee wäre, dass Abhängigkeiten, die als Teil der „leeren“ Extras installiert werden, nur dann installiert werden, wenn kein anderes Extra angegeben wurde. Eine Implementierung davon wurde in https://github.com/pypa/setuptools/pull/1503 vorgeschlagen, aber es wurde festgestellt, dass es keine Möglichkeit gäbe, dies zu erreichen, ohne die Kompatibilität mit bestehender Nutzung zu brechen. Zum Beispiel können Pakete, die Setuptools über eine setup.py-Datei verwenden, Folgendes tun:

setup(
    ...
    extras_require={'': ['package_a']},
)

was gültig und äquivalent zu package_a ist, das in install_requires definiert ist, so dass die Änderung der Bedeutung des leeren Strings die Kompatibilität brechen würde.

Darüber hinaus kann kein anderer String (wie z. B. 'default') als spezieller String verwendet werden, da alle Strings, die ein rückwärtskompatibler gültiger Extras-Name wären, bereits in bestehenden Paketen verwendet werden können.

Es gab Vorschläge zur Verwendung der speziellen Python-Variable None, aber auch dies ist nicht möglich, da, obwohl man None in einer setup.py-Datei verwenden kann, dies in deklarativen Dateien wie setup.cfg oder pyproject.toml nicht möglich ist, und außerdem müssen Extra-Namen letztendlich in die Paketmetadaten in Strings umgewandelt werden. Das Haben

Provides-Extra: None

wäre nicht zu unterscheiden von dem String „None“, der möglicherweise bereits als Extra-Name in einem Python-Paket verwendet wird. Wenn wir die Kern-Metadatensyntax ändern würden, um nicht-String „spezielle“ Extra-Namen zuzulassen, dann wären wir wieder dabei, die Kern-Metadatenspezifikation zu ändern, was nicht besser ist als die Einführung von Default-Extra.

Verlassen auf Werkzeuge zum Abwählen von Standard-Extras

Eine weitere Option zur Abwahl von Extras wäre die Implementierung auf Ebene der Packaging-Tools. Zum Beispiel könnte pip eine Option wie

$ pip install package --no-default-extras

Diese Option könnte für alle oder bestimmte Pakete gelten, ähnlich der Option --no-binary, z. B.:

$ pip install package --no-default-extras :all:

Der Vorteil dieses Ansatzes ist, dass Tools, die Standard-Extras unterstützen, diese auch unterstützen könnten, sie abzuwählen. Dieser Ansatz wäre ähnlich der Option --no-install-recommends für das apt-Tool.

Dieser Lösungsansatz ist jedoch allein nicht ideal, da er es Paketen nicht ermöglichen würde, selbst anzugeben, dass sie einige der Standard-Extras einer Abhängigkeit nicht benötigen. Er wäre auch mit Risiken für Benutzer verbunden, die möglicherweise alle Standard-Extras in einem großen Abhängigkeitsbaum deaktivieren und dabei möglicherweise Pakete im Baum brechen, die sich an irgendeiner Stelle auf Standard-Extras verlassen.

Dennoch schließt dieser PEP diesen Ansatz nicht aus, und es liegt an den Betreuern der verschiedenen Packaging-Tools zu entscheiden, ob sie diese Art von Option unterstützen möchten. Es ist ein Flag, das zumindest für Paketbetreuer nützlich sein könnte, die Orte in Abhängigkeitsbäumen identifizieren möchten, an denen Standard-Extras genutzt werden. Wenn er jedoch unterstützt wird, sollte klargestellt werden, dass die Verwendung dieses Flags keine funktionierende Umgebung garantiert.