Einschränkungen von requirements.txt-Dateien

Viele Projekte können eine oder mehrere requirements.txt-Dateien definieren und sie entweder im Stammverzeichnis des Projekts (z.B. requirements.txt und test-requirements.txt) oder in einem Verzeichnis (z.B. requirements/base.txt und requirements/test.txt) anordnen. Es gibt jedoch wesentliche Probleme bei der Verwendung von Anforderungsdateien auf diese Weise:

• Es gibt keine standardisierte Namenskonvention, so dass Werkzeuge diese Dateien anhand ihres Namens entdecken oder verwenden können.
• requirements.txt-Dateien sind *nicht standardisiert*, sondern bieten Optionen für pip.

Daher ist es schwierig, Werkzeugverhalten basierend auf requirements.txt-Dateien zu definieren. Sie sind nicht einfach zu entdecken oder nach Namen zu identifizieren, und ihr Inhalt kann eine Mischung aus Paket-Spezifizierern und zusätzlichen pip-Optionen enthalten.

Das Fehlen eines Standards für den Inhalt von requirements.txt bedeutet auch, dass sie nicht auf andere Werkzeuge portierbar sind, die sie verarbeiten möchten, abgesehen von pip.

Darüber hinaus erfordern requirements.txt-Dateien eine Datei pro Abhängigkeitsliste. Für einige Anwendungsfälle macht dies die Grenzkosten von Abhängigkeitsgruppierungen hoch im Verhältnis zu ihrem Nutzen. Eine knappere Deklaration ist für Projekte mit einer Anzahl kleiner Abhängigkeitsgruppen von Vorteil.

Im Gegensatz dazu werden Abhängigkeitsgruppen an einem bekannten Ort in pyproject.toml mit vollständig standardisiertem Inhalt definiert. Sie werden nicht nur sofort nutzbar sein, sondern auch als Ausgangspunkt für zukünftige Standards dienen.

Einschränkungen von extras

extras sind zusätzliche Paketmetadaten, die in der Tabelle [project.optional-dependencies] deklariert werden. Sie bieten Namen für Listen von Paket-Spezifizierern, die als Teil der Metadaten eines Pakets veröffentlicht werden und die ein Benutzer unter diesem Namen anfordern kann, wie z.B. pip install 'foo[bar]', um foo mit dem bar-Extra zu installieren.

Da extras Paketmetadaten sind, ist nicht garantiert, dass sie statisch definiert sind und möglicherweise ein Build-System zur Auflösung benötigen. Darüber hinaus deutet die Definition von [project.optional-dependencies] für viele Werkzeuge darauf hin, dass ein Projekt ein Paket ist, und kann Werkzeugverhalten auslösen, wie z.B. die Validierung der [project]-Tabelle.

Für Projekte, die Pakete sind, sind extras eine gängige Lösung zur Definition von Entwicklungsabhängigkeiten, aber auch unter diesen Umständen haben sie Nachteile:

• Da ein extra optionale *zusätzliche* Abhängigkeiten definiert, ist es nicht möglich, ein extra zu installieren, ohne das aktuelle Paket und seine Abhängigkeiten zu installieren.
• Da sie für Benutzer installierbar sind, sind extras Teil der öffentlichen Schnittstelle von Paketen. Da extras veröffentlicht werden, sind Paketentwickler oft besorgt darüber, sicherzustellen, dass ihre Entwicklungs-Extras nicht mit benutzerorientierten Extras verwechselt werden.

Anwendungsfälle

Die folgenden Anwendungsfälle werden als wichtige Ziele für diese PEP betrachtet. Sie sind im Anhang Anwendungsfälle detaillierter definiert.

• Webanwendungen, die über einen Nicht-Python-Packaging-Build-Prozess bereitgestellt werden
• Bibliotheken mit nicht veröffentlichten Entwicklungsabhängigkeitsgruppen
• Data Science Projekte mit Abhängigkeitsgruppen, aber ohne Kernpaket
• Eingabedaten für die Lockfile-Generierung (Abhängigkeitsgruppen sollten im Allgemeinen nicht als Speicherort für gesperrte Abhängigkeitsdaten verwendet werden)
• Eingabedaten für einen Umgebungsmanager wie tox, Nox oder Hatch
• Konfigurierbare IDE-Erkennung von Test- und Linter-Anforderungen

Zu Poetry und PDM Abhängigkeitsgruppen

Die bestehenden Werkzeuge Poetry und PDM bieten bereits eine Funktion, die jeder „Abhängigkeitsgruppen“ nennt. In Ermangelung eines Standards für die Angabe von Abhängigkeits-Sammlungen definiert jedes Werkzeug diese auf eine werkzeugspezifische Weise in den entsprechenden Abschnitten der [tool]-Tabelle.

(PDM verwendet auch Extras für einige Abhängigkeitsgruppen und überschneidet die Vorstellung stark mit Extras.)

Diese PEP unterstützt nicht alle Funktionen von Poetry und PDM, die, wie requirements.txt-Dateien für pip, mehrere nicht standardmäßige Erweiterungen gängiger Abhängigkeits-Spezifizierer unterstützen.

Es sollte möglich sein, dass solche Werkzeuge standardisierte Abhängigkeitsgruppen als Erweiterungen ihrer eigenen Abhängigkeitsgruppen-Mechanismen nutzen. Die Definition eines neuen Datenformats, das die bestehenden Poetry- und PDM-Lösungen ersetzt, ist jedoch kein Ziel. Dies würde die Standardisierung mehrerer zusätzlicher Funktionen erfordern, wie z.B. Pfadabhängigkeiten, die von diesen Werkzeugen unterstützt werden.

Abhängigkeitsgruppen sind keine versteckten Extras

Abhängigkeitsgruppen ähneln stark nicht veröffentlichten Extras. Es gibt jedoch zwei Hauptfunktionen, die sie weiter von Extras unterscheiden:

• sie unterstützen Nicht-Paket-Projekte
• Die Installation einer Abhängigkeitsgruppe impliziert nicht die Installation der Abhängigkeiten eines Pakets (oder des Pakets selbst)

Zukunftskompatibilität & Ungültige Daten

Abhängigkeitsgruppen sind dafür vorgesehen, in zukünftigen PEPs erweiterbar zu sein. Abhängigkeitsgruppen sollten jedoch auch von mehreren Werkzeugen in einem einzigen Python-Projekt nutzbar sein. Mit mehreren Werkzeugen, die dieselben Daten verwenden, ist es möglich, dass eines eine zukünftige PEP implementiert, die Abhängigkeitsgruppen erweitert, während ein anderes dies nicht tut.

Um Benutzer in diesem Fall zu unterstützen, definiert und empfiehlt diese PEP Validierungsverhalten, bei dem Werkzeuge nur die Abhängigkeitsgruppen prüfen, die sie verwenden. Dies ermöglicht es mehreren Werkzeugen, die unterschiedliche Versionen von Abhängigkeitsgruppen-Daten verwenden, eine einzige Tabelle in pyproject.toml zu teilen.

Abhängigkeitsobjektspezifizierer

Abhängigkeitsobjektspezifizierer sind Tabellen, die null oder mehr Abhängigkeiten definieren.

Diese PEP standardisiert nur einen Typ von Abhängigkeitsobjektspezifizierer, eine „Abhängigkeitsgruppen-Einbindung“. Andere Typen können in zukünftigen Standards hinzugefügt werden.

[dependency-groups]
group-a = ["foo"]
group-b = ["foo>1.0"]
group-c = ["foo<1.0"]
all = ["foo", {include-group = "group-a"}, {include-group = "group-b"}, {include-group = "group-c"}]

Beispiel: Tabelle für Abhängigkeitsgruppen

Das Folgende ist ein Beispiel für eine teilweise pyproject.toml, die dies zur Definition von vier Abhängigkeitsgruppen verwendet: test, docs, typing und typing-test

[dependency-groups]
test = ["pytest", "coverage"]
docs = ["sphinx", "sphinx-rtd-theme"]
typing = ["mypy", "types-requests"]
typing-test = [{include-group = "typing"}, {include-group = "test"}, "useful-types"]

Beachten Sie, dass keine dieser Abhängigkeitsgruppen-Deklarationen implizit das aktuelle Paket, seine Abhängigkeiten oder optionale Abhängigkeiten installiert. Die Verwendung einer Abhängigkeitsgruppe wie test zum Testen eines Pakets erfordert, dass die Konfiguration oder Toolchain des Benutzers auch das aktuelle Paket (.) installiert. Zum Beispiel:

$TOOL install-dependency-group test
pip install -e .

könnte verwendet werden (vorausgesetzt, $TOOL ist ein Werkzeug, das die Installation von Abhängigkeitsgruppen unterstützt), um eine Testumgebung aufzubauen.

Dies ermöglicht es auch, dass die Abhängigkeitsgruppe docs verwendet werden kann, ohne das Projekt als Paket zu installieren.

$TOOL install-dependency-group docs

Paketbau

Build-Backends DÜRFEN keine Abhängigkeitsgruppen-Daten in erstellten Distributionen als Paketmetadaten einfügen. Das bedeutet, dass PKG-INFO in sdists und METADATA in wheels keine referenzierbaren Felder enthalten, die Abhängigkeitsgruppen enthalten.

Es ist gültig, Abhängigkeitsgruppen bei der Auswertung dynamischer Metadaten zu verwenden, und pyproject.toml-Dateien, die in sdists enthalten sind, enthalten natürlich weiterhin die Tabelle [dependency-groups]. Die Tabelleninhalte sind jedoch kein Teil der Schnittstellen eines veröffentlichten Pakets.

Installation von Abhängigkeitsgruppen

Von Werkzeugen, die Abhängigkeitsgruppen unterstützen, wird erwartet, dass sie neue Optionen und Schnittstellen bereitstellen, um Benutzern die Installation aus Abhängigkeitsgruppen zu ermöglichen.

Es wird keine Syntax für die Darstellung der Abhängigkeitsgruppen eines Pakets definiert, aus zwei Gründen:

• es wäre nicht gültig, auf die Abhängigkeitsgruppen eines Drittanbieterpakets von PyPI zu verweisen (da die Daten als unveröffentlicht definiert sind)
• es gibt keine Garantie, dass es ein aktuelles Paket für Abhängigkeitsgruppen gibt – ein Teil ihres Zwecks ist die Unterstützung von Nicht-Paket-Projekten

Zum Beispiel wäre eine mögliche Pip-Schnittstelle zur Installation von Abhängigkeitsgruppen:

pip install --dependency-groups=test,typing

Beachten Sie, dass dies nur ein Beispiel ist. Diese PEP definiert keine Anforderungen, wie Werkzeuge die Installation von Abhängigkeitsgruppen unterstützen.

Validierung und Kompatibilität

Werkzeuge, die Abhängigkeitsgruppen unterstützen, möchten möglicherweise Daten validieren, bevor sie sie verwenden. Werkzeuge, die ein solches Validierungsverhalten implementieren, sollten jedoch darauf achten, zukünftige Erweiterungen dieser Spezifikation zuzulassen, damit sie nicht unnötigerweise Fehler oder Warnungen bei Vorhandensein neuer Syntax ausgeben.

Werkzeuge SOLLTEN einen Fehler ausgeben, wenn sie nicht erkannte Daten in Abhängigkeitsgruppen auswerten oder verarbeiten.

Werkzeuge SOLLTEN die Listeninhalte von *allen* Abhängigkeitsgruppen nicht eifrig validieren.

Dies bedeutet, dass bei Vorhandensein der folgenden Daten die meisten Werkzeuge die Verwendung der Gruppe foo zulassen und nur einen Fehler ausgeben, wenn die Gruppe bar verwendet wird.

[dependency-groups]
foo = ["pyparsing"]
bar = [{set-phasers-to = "stun"}]

Audit- und Update-Tools

Eine breite Palette von Werkzeugen versteht Python-Abhängigkeitsdaten, wie sie in requirements.txt-Dateien ausgedrückt werden. (z.B. Dependabot, Tidelift usw.)

Solche Werkzeuge inspizieren Abhängigkeitsdaten und bieten in einigen Fällen werkzeuggestützte oder vollständig automatisierte Updates. Wir erwarten, dass keine solchen Werkzeuge die neuen Abhängigkeitsgruppen zunächst unterstützen werden, und eine breite Ökosystem-Unterstützung könnte viele Monate oder sogar einige Jahre dauern, bis sie eintrifft.

Daher würden Benutzer von Abhängigkeitsgruppen zum Zeitpunkt der Verwendung von Abhängigkeitsgruppen eine Verschlechterung ihrer Arbeitsabläufe und Werkzeugunterstützung erfahren. Dies gilt für jeden neuen Standard, wo und wie Abhängigkeitsdaten kodiert werden.

Schnittstellen zur Nutzung von Abhängigkeitsgruppen

Diese Spezifikation bietet keine universelle Schnittstelle für die Interaktion mit Abhängigkeitsgruppen, außer der Einbeziehung in ein erstelltes Paket über die project-Tabelle. Dies hat Auswirkungen sowohl auf Werkzeugentwickler als auch auf Benutzer.

Werkzeugentwickler sollten bestimmen, wie oder ob Abhängigkeitsgruppen für ihre User Stories relevant sind und ihre eigenen Schnittstellen erstellen, die dazu passen. Für Umgebungsmanager, Resolver, Installer und verwandte Nicht-Build-Tools können sie dokumentieren, dass sie „PEP 735 Abhängigkeitsgruppen“ unterstützen, sind aber für die Dokumentation ihrer Nutzungsmodi verantwortlich. Für Build-Backends erfordert die Unterstützung von Abhängigkeitsgruppen die Unterstützung der Einbeziehung aus der project-Tabelle, schreibt aber keine anderen strengen Anforderungen vor.

Für Benutzer ist die primäre Konsequenz, dass sie die jeweilige Werkzeugdokumentation konsultieren müssen, wann immer sie Abhängigkeitsgruppen außerhalb von Paket-Builds verwenden möchten. Benutzer sollten von Werkzeugen, entweder durch Dokumentation oder Laufzeitwarnungen oder -fehler, über Verwendungen informiert werden, die nicht empfohlen oder nicht unterstützt werden. Wenn ein Werkzeug beispielsweise verlangt, dass alle Abhängigkeitsgruppen gegenseitig kompatibel sind und keine widersprüchlichen Paketspezifizierer enthalten, sollte es diese Einschränkung dokumentieren und Benutzer informieren, wie sie Abhängigkeitsgruppen für seine Zwecke richtig nutzen.

Warum nicht jede Abhängigkeitsgruppe als Tabelle definieren?

Wenn unser Ziel die Erweiterbarkeit in der Zukunft ist, dann ermöglicht die Definition jeder Abhängigkeitsgruppe als Untertabelle, wodurch wir zukünftige Schlüssel an jede Gruppe anhängen können, die größte zukünftige Flexibilität.

Dies macht die Struktur jedoch tiefer verschachtelt und daher schwieriger zu lehren und zu lernen. Eines der Ziele dieser PEP ist es, ein einfacher Ersatz für viele requirements.txt-Anwendungsfälle zu sein.

Warum keine spezielle String-Syntax zur Erweiterung von Abhängigkeitsspezifizierern definieren?

Frühere Entwürfe dieser Spezifikation definierten syntaktische Formen für Abhängigkeitsgruppen-Einbindungen und Pfadabhängigkeiten.

Es gab jedoch drei Hauptprobleme bei diesem Ansatz:

• es verkompliziert die Zeichenketten-Syntax, die gelehrt werden muss, über PEP 508 hinaus
• die resultierenden Zeichenketten müssten immer von PEP 508-Spezifizierern disambiguiert werden, was die Implementierungen verkompliziert

Warum nicht mehr Nicht-PEP 508 Abhängigkeitsspezifizierer zulassen?

Mehrere Anwendungsfälle, die während der Diskussion aufkamen, benötigen expressivere Spezifizierer als mit PEP 508 möglich sind.

„Pfadabhängigkeiten“, die sich auf lokale Pfade beziehen, und Verweise auf [project.dependencies] waren von besonderem Interesse.

Es gibt jedoch keine bestehenden Standards für diese Funktionen (abgesehen vom De-facto-Standard der Implementierungsdetails von pip).

Als Ergebnis führt der Versuch, diese Funktionen in diese PEP aufzunehmen, zu einer erheblichen Ausweitung des Umfangs, um zu versuchen, diese verschiedenen Funktionen und pip-Verhaltensweisen zu standardisieren.

Besondere Aufmerksamkeit wurde dem Versuch gewidmet, die Angabe von Editier-Installationen zu standardisieren, wie sie von pip install -e und PEP 660 ausgedrückt werden. Obwohl die Erstellung von Editier-Installationen für Build-Backends standardisiert ist, ist das Verhalten von Editier-Installationen für Installer nicht standardisiert. Die Aufnahme von Editier-Installationen in diese PEP erfordert, dass jedes unterstützende Werkzeug die Installation von Editier-Installationen ermöglicht.

Daher werden, obwohl Poetry und PDM Syntaxen für einige dieser Features bereitstellen, diese derzeit als nicht ausreichend standardisiert für die Aufnahme in Dependency Groups angesehen.

Warum heißt die Tabelle nicht [run], [project.dependency-groups], …?

Es gibt viele mögliche Namen für dieses Konzept. Es wird neben den bereits existierenden Tabellen [project.dependencies] und [project.optional-dependencies] bestehen müssen, und möglicherweise auch einer neuen Tabelle für externe Abhängigkeiten [external] (zum Zeitpunkt der Erstellung ist PEP 725, die die Tabelle [external] definiert, in Bearbeitung).

[run] war ein führender Vorschlag in früheren Diskussionen, aber seine vorgeschlagene Verwendung konzentrierte sich auf einen einzigen Satz von Laufzeitabhängigkeiten. Dieses PEP umreißt explizit mehrere Gruppen von Abhängigkeiten, was [run] zu einer weniger geeigneten Wahl macht – dies sind nicht nur Abhängigkeitsdaten für einen bestimmten Laufzeitkontext, sondern für mehrere Kontexte.

[project.dependency-groups] würde eine schöne Parallele zu [project.dependencies] und [project.optional-dependencies] bieten, hat aber erhebliche Nachteile für Nicht-Paket-Projekte. [project] erfordert die Definition mehrerer Schlüssel wie name und version. Die Verwendung dieses Namens würde entweder eine Neudefinition der Tabelle [project] erfordern, um das Fehlen dieser Schlüssel zu erlauben, oder Nicht-Paket-Projekte dazu zwingen, diese Schlüssel zu definieren und zu verwenden. Dadurch würde es effektiv erforderlich, dass jedes Nicht-Paket-Projekt sich selbst als Paket behandeln lässt.

Warum ist Pips geplante Implementierung von --only-deps nicht ausreichend?

pip hat derzeit eine Funktion auf der Roadmap, die ein Flag –only-deps hinzufügt. Dieses Flag soll es Benutzern ermöglichen, Paketabhängigkeiten und Extras zu installieren, ohne das aktuelle Paket zu installieren.

Es adressiert nicht die Bedürfnisse von Nicht-Paket-Projekten und erlaubt auch nicht die Installation eines Extras ohne die Paketabhängigkeiten.

Warum ist <Umgebungsmanager> keine Lösung?

Bestehende Umgebungsmanager wie tox, Nox und Hatch haben bereits die Fähigkeit, inline Abhängigkeiten als Teil ihrer Konfigurationsdaten aufzulisten. Dies erfüllt viele Bedürfnisse an Entwicklungabhängigkeiten und ordnet Abhängigkeitsgruppen klar den relevanten auszuführbaren Aufgaben zu. Diese Mechanismen sind *gut*, aber sie sind nicht *ausreichend*.

Erstens adressieren sie nicht die Bedürfnisse von Nicht-Paket-Projekten.

Zweitens gibt es keinen Standard, den andere Werkzeuge verwenden können, um auf diese Daten zuzugreifen. Dies hat Auswirkungen auf High-Level-Tools wie IDEs und Dependabot, die keine tiefe Integration mit diesen Dependency Groups unterstützen können. (Zum Beispiel wird Dependabot zum Zeitpunkt der Erstellung keine Abhängigkeiten markieren, die in tox.ini-Dateien angepinnt sind.)

Warum Abhängigkeitsgruppen-Einbindungen nicht in [project.dependencies] oder [project.optional-dependencies] unterstützen?

Frühere Entwürfe dieser Spezifikation erlaubten die Verwendung von Dependency Group Includes in der Tabelle [project]. Während des Community-Feedbacks wurden jedoch mehrere Probleme angesprochen, die zu seiner Entfernung führten.

Nur eine kleine Anzahl zusätzlicher Anwendungsfälle würde durch die Aufnahme von Dependency Groups abgedeckt, und dies erhöhte den Umfang der Spezifikation erheblich. Insbesondere würde diese Aufnahme die Anzahl der beteiligten Parteien erhöhen. Viele Leser der Tabelle [project], einschließlich Build-Backends, SBOM-Generatoren und Abhängigkeitsanalysatoren, sind von einer Änderung an [project] betroffen, können aber bei einer neuen (aber nicht verbundenen) Tabelle [dependency-groups] weiterhin wie bisher funktionieren.

Getrennt von der obigen Bedenken ermutigt die Erlaubnis zur Aufnahme von Abhängigkeitsgruppen aus der Tabelle [project] Paketbetreuer, Abhängigkeitsmetadaten vom aktuellen Standardspeicherort zu verschieben. Dies erschwert statische pyproject.toml Metadaten und steht im Widerspruch zum Ziel von PEP 621, Abhängigkeitsmetadaten an einem einzigen Ort zu speichern.

Schließlich ist der Ausschluss der Unterstützung für [project] aus diesem PEP nicht endgültig. Die Verwendung von Includes aus dieser Tabelle oder eine Include-Syntax von [dependency-groups] in [project] könnte durch ein zukünftiges PEP eingeführt und eigenständig bewertet werden.

[project]
dependencies = [{include = "runtime"}]
[optional-dependencies]
foo = [{include = "foo"}]
[dependency-groups]
runtime = ["a", "b"]
foo = ["c", "d"]
typing = ["mypy", {include = "runtime"}, {include = "foo"}]

Warum Abhängigkeitsgruppen-Einbindungen nicht in [build-system.requires] unterstützen?

Da wir die Verwendung von Dependency Groups in [project] nicht zulassen werden, kann [build-system.requires] im Vergleich zu [project.dependencies] betrachtet werden.

Es gibt weniger theoretische Anwendungsfälle für Build-Anforderungen, die in einer Gruppe spezifiziert sind, als für Paket-Anforderungen. Darüber hinaus impliziert die Auswirkung einer solchen Änderung den PEP 517 Frontend, das Dependency Groups unterstützen müsste, um eine Build-Umgebung vorzubereiten.

Im Vergleich zu Änderungen an [project.dependencies] und [project.optional-dependencies] hat die Änderung des Verhaltens von [build-system.requires] eine höhere Auswirkung und weniger potenzielle Nutzungen. Daher wird, da dieses PEP keine Änderungen an der Tabelle [project] vornimmt, auch die Änderung von [build-system] zurückgestellt.

Warum keine Abhängigkeitsgruppe unterstützen, die das aktuelle Projekt einschließt?

Mehrere Anwendungsfälle für Dependency Groups beinhalten die Installation einer Dependency Group zusammen mit einem Paket, das in der Tabelle [project] definiert ist. Zum Beispiel beinhaltet das Testen eines Pakets die Installation von Testabhängigkeiten und des Pakets selbst. Darüber hinaus ist die Kompatibilität einer Dependency Group mit dem Hauptpaket eine wertvolle Eingabe für Lockfile-Generatoren.

In solchen Fällen ist es wünschenswert, dass eine Dependency Group deklariert, dass sie vom Projekt selbst abhängt. Beispiel-Syntaxes aus Diskussionen waren {include-project = true} und {include-group = ":project:"}.

Wenn jedoch eine Spezifikation zur Erweiterung von PEP 508 um Pfadabhängigkeiten festgelegt wird, würde dies dazu führen, dass Dependency Groups zwei Möglichkeiten haben, das Hauptpaket zu spezifizieren. Wenn beispielsweise . formal unterstützt wird und {include-project = true} in diesem PEP enthalten ist, können Dependency Groups eine der folgenden Gruppen spezifizieren

[dependency-groups]
case1 = [{include-project = true}]
case2 = ["."]
case3 = [{include-project = true}, "."]
case4 = [{include-project = false}, "."]

Um eine verwirrende Zukunft zu vermeiden, in der mehrere verschiedene Optionen das in pyproject.toml definierte Paket spezifizieren, wird jede Syntax zur Deklaration dieser Beziehung aus diesem PEP weggelassen.

JavaScript und package.json

In der JavaScript-Community enthalten Pakete eine kanonische Konfigurations- und Datendatei, ähnlich im Umfang wie pyproject.toml, unter package.json.

Zwei Schlüssel in package.json steuern die Abhängigkeitsdaten: "dependencies" und "devDependencies". Die Rolle von "dependencies" ist effektiv dieselbe wie die von [project.dependencies] in pyproject.toml und deklariert die direkten Abhängigkeiten eines Pakets.

{
    "dependencies": {
        "@angular/compiler": "^17.0.2",
        "camelcase": "8.0.0",
        "diff": ">=5.1.0 <6.0.0"
    }
}

{
    "dependencies": {
        "my-package": "file:../foo"
    }
}

{
    "peerDependencies": {
        "foo": "2.x"
    }
}

{
    "peerDependencies": {
        "foo": "2.x"
    },
    "peerDependenciesMeta": {
        "foo": {
            "optional": true
        }
    }
}

Ruby & Ruby Gems

Ruby-Projekte sind möglicherweise nicht dazu bestimmt, Pakete („Gems“) im Ruby-Ökosystem zu produzieren. Tatsächlich ist die Erwartung, dass die meisten Benutzer der Sprache keine Gems produzieren wollen und kein Interesse daran haben, ihre eigenen Pakete zu erstellen. Viele Tutorials berühren nicht, wie Pakete erstellt werden, und die Toolchain erfordert niemals Benutzercode, der für unterstützte Anwendungsfälle verpackt wird.

Ruby teilt die Spezifikation von Anforderungen in zwei separate Dateien auf.

• Gemfile: eine dedizierte Datei, die nur Anforderungsdaten in Form von Abhängigkeitsgruppen unterstützt
• <package>.gemspec: eine dedizierte Datei zur Deklaration von Paket- (Gem-) Metadaten

Das Werkzeug bundler, das den Befehl bundle bereitstellt, ist die primäre Schnittstelle zur Verwendung von Gemfile-Daten.

Das Werkzeug gem ist für die Erstellung von Gems aus .gemspec-Daten über den Befehl gem build zuständig.

source 'https://rubygems.org'

gem 'rails'

group :test do
  gem 'rspec'
end

group :lint do
  gem 'rubocop'
end

group :docs do
  gem 'kramdown'
  gem 'nokogiri'
end

version = '7.1.2'

Gem::Specification.new do |s|
  s.platform    = Gem::Platform::RUBY
  s.name        = "rails"
  s.version     = version
  s.summary     = "Full-stack web application framework."

  s.license = "MIT"
  s.author   = "David Heinemeier Hansson"

  s.files = ["README.md", "MIT-LICENSE"]

  # shortened from the real 'rails' project
  s.add_dependency "activesupport", version
  s.add_dependency "activerecord",  version
  s.add_dependency "actionmailer",  version
  s.add_dependency "activestorage", version
  s.add_dependency "railties",      version
end

s.add_dependency "rexml"
s.add_development_dependency 'minitest', '~> 5.0'
s.add_development_dependency 'rouge', '~> 3.0', '>= 3.26.0'
s.add_development_dependency 'stringex', '~> 1.5.1'

Gem::Specification.new do |s|
  s.author = 'Stephen Rosen'
  s.name = 'cool-gem'
  s.version = '0.0.1'
  s.summary = 'A very cool gem that does cool stuff'
  s.license = 'MIT'

  s.files = []

  s.add_dependency 'rails'
  s.add_development_dependency 'kramdown'
end

source 'https://rubygems.org'

gemspec

gem 'cool-gem', :path => '.'

group :development do
  gem 'kramdown'
end

Projekte sind Pakete

Sowohl PDM als auch Poetry behandeln die von ihnen unterstützten Projekte als Pakete. Dies erlaubt ihnen, Standard-Metadaten von pyproject.toml für einige ihrer Bedürfnisse zu verwenden und zu interagieren, und erlaubt ihnen, die Installation des „aktuellen Projekts“ zu unterstützen, indem sie einen Build und eine Installation mit ihren Build-Backends durchführen.

Effektiv bedeutet dies, dass weder Poetry noch PDM Nicht-Paket-Projekte unterstützt.

Nicht standardisierte Abhängigkeitsspezifizierer

PDM und Poetry erweitern PEP 508 Abhängigkeitsspezifikatoren um zusätzliche Features, die nicht Teil eines gemeinsamen Standards sind. Die beiden Tools verwenden jedoch leicht unterschiedliche Ansätze für diese Probleme.

PDM unterstützt die Spezifikation lokaler Pfade und editierbarer Installationen über eine Syntax, die wie eine Reihe von Argumenten für pip install aussieht. Zum Beispiel beinhaltet die folgende Abhängigkeitsgruppe ein lokales Paket im Editier-Modus

[tool.pdm.dev-dependencies]
mygroup = ["-e file:///${PROJECT_ROOT}/foo"]

Dies deklariert eine Abhängigkeitsgruppe mygroup, die eine lokale, editierbare Installation aus dem Verzeichnis foo enthält.

Poetry beschreibt Abhängigkeitsgruppen als Tabellen, die Paketnamen auf Spezifikatoren abbilden. Zum Beispiel könnte die gleiche Konfiguration wie das obige mygroup-Beispiel unter Poetry wie folgt aussehen

[tool.poetry.group.mygroup]
foo = { path = "foo", editable = true }

PDM beschränkt sich auf eine String-Syntax, während Poetry Tabellen einführt, die Abhängigkeiten beschreiben.

Installation und Referenzierung von Abhängigkeitsgruppen

Sowohl PDM als auch Poetry haben Tool-spezifische Unterstützung für die Installation von Abhängigkeitsgruppen. Da beide Projekte ihre eigenen Lockfile-Formate unterstützen, haben sie auch beide die Fähigkeit, einen Abhängigkeitsgruppennamen transparent zu verwenden, um auf die *gesperrten* Abhängigkeitsdaten für diese Gruppe zu verweisen.

Keines der Tools Abhängigkeitsgruppen kann jedoch nativ von anderen Tools wie tox, nox oder pip referenziert werden. Der Versuch, eine Abhängigkeitsgruppe unter tox zu installieren, erfordert beispielsweise einen expliziten Aufruf von PDM oder Poetry, um deren Abhängigkeitsdaten zu parsen und den entsprechenden Installationsschritt durchzuführen.

Webanwendungen

Eine Webanwendung (z.B. eine Django- oder Flask-App) muss oft keine Distribution erstellen, sondern bündelt und liefert ihren Quellcode an eine Deployment-Toolchain.

Zum Beispiel kann ein Quellcode-Repository Python-Paketierungsmetadaten sowie Containerisierungs- oder andere Build-Pipeline-Metadaten (Dockerfile, etc.) definieren. Die Python-Anwendung wird erstellt, indem das gesamte Repository in einen Build-Kontext kopiert, Abhängigkeiten installiert und das Ergebnis als Maschinen-Image oder Container gebündelt wird.

Solche Anwendungen haben Abhängigkeitsgruppen für den Build, aber auch für Linting, Testing usw. In der Praxis definieren diese Anwendungen heute oft selbst als Pakete, um Paketierungs-Tools und -Mechanismen wie extras zur Verwaltung ihrer Abhängigkeitsgruppen nutzen zu können. Sie sind jedoch konzeptionell keine Pakete, die in sdist- oder Wheel-Format zur Verteilung bestimmt sind.

Dependency Groups ermöglichen es diesen Anwendungen, ihre verschiedenen Abhängigkeiten zu definieren, ohne auf Paketierungsmetadaten angewiesen zu sein und ohne zu versuchen, ihre Bedürfnisse in Paketierungstermen auszudrücken.

Bibliotheken

Bibliotheken sind Python-Pakete, die Distributionen (sdist und wheel) erstellen und sie auf PyPI veröffentlichen.

Für Bibliotheken stellen Dependency Groups eine Alternative zu extras zur Definition von Gruppen von Entwicklung-Abhängigkeiten dar, mit den wichtigen oben genannten Vorteilen.

Eine Bibliothek kann Gruppen für test und typing definieren, die Tests und Typüberprüfung ermöglichen, und somit auf die eigenen Abhängigkeiten der Bibliothek angewiesen sein (wie in [project.dependencies] spezifiziert).

Andere Entwicklungsbedürfnisse erfordern möglicherweise gar keine Installation des Pakets. Zum Beispiel kann eine lint Dependency Group gültig und schneller zu installieren sein, ohne die Bibliothek, da sie nur Tools wie black, ruff oder flake8 installiert.

lint und test Umgebungen können auch wertvolle Orte sein, um IDE- oder Editor-Unterstützung einzubinden. Siehe den unten stehenden Fall für eine ausführlichere Beschreibung einer solchen Verwendung.

Hier ist eine Beispiel-Dependency-Groups-Tabelle, die für eine Bibliothek geeignet sein könnte

[dependency-groups]
test = ["pytest<8", "coverage"]
typing = ["mypy==1.7.1", "types-requests"]
lint = ["black", "flake8"]
typing-test = [{include-group = "typing"}, "pytest<8"]

Beachten Sie, dass keine dieser Gruppen implizit die Bibliothek selbst installiert. Es liegt daher in der Verantwortung jeder Umgebungsmanagement-Toolchain, die entsprechenden Dependency Groups zusammen mit der Bibliothek zu installieren, wenn nötig, wie im Fall von test.

Data Science Projekte

Data Science Projekte nehmen typischerweise die Form einer logischen Sammlung von Skripten und Dienstprogrammen zur Verarbeitung und Analyse von Daten unter Verwendung einer gemeinsamen Toolchain an. Komponenten können im Jupyter Notebook-Format (ipynb) definiert werden, basieren aber auf demselben gemeinsamen Kernsatz von Dienstprogrammen.

In einem solchen Projekt gibt es kein Paket zu erstellen oder zu installieren. Daher bietet pyproject.toml derzeit keine Lösung für das Abhängigkeitsmanagement oder die Deklaration.

Es ist für ein solches Projekt wertvoll, mindestens eine Hauptgruppierung von Abhängigkeiten definieren zu können. Zum Beispiel

[dependency-groups]
main = ["numpy", "pandas", "matplotlib"]

Es kann jedoch auch notwendig sein, dass verschiedene Skripte zusätzliche unterstützende Werkzeuge benötigen. Projekte können sogar widersprüchliche oder inkompatible Werkzeuge oder Werkzeugversionen für verschiedene Komponenten haben, wenn diese sich im Laufe der Zeit weiterentwickeln.

Betrachten Sie die folgende aufwendigere Konfiguration

[dependency-groups]
main = ["numpy", "pandas", "matplotlib"]
scikit = [{include-group = "main"}, "scikit-learn==1.3.2"]
scikit-old = [{include-group = "main"}, "scikit-learn==0.24.2"]

Dies definiert scikit und scikit-old als zwei ähnliche Varianten der üblichen Abhängigkeitssuite, die unterschiedliche Versionen von scikit-learn für verschiedene Skripte einbinden.

Diese PEP definiert nur diese Daten. Sie formalisiert keinen Mechanismus für ein Data Science Projekt (oder irgendeinen anderen Projekttyp), um die Abhängigkeiten in bekannten Umgebungen zu installieren oder diese Umgebungen mit den verschiedenen Skripten zu verknüpfen. Solche Datenkombinationen bleiben ein Problem für Toolautoren, das gelöst und vielleicht irgendwann standardisiert werden muss.

Lockfile-Generierung

Es gibt heute eine Reihe von Tools, die Lockfiles im Python-Ökosystem generieren. PDM und Poetry verwenden jeweils ihre eigenen Lockfile-Formate, und pip-tools generiert requirements.txt-Dateien mit Versions-Pins und Hashes.

Abhängigkeitsgruppen sind kein geeigneter Ort zur Speicherung von Lockfiles, da ihnen viele der notwendigen Funktionen fehlen. Am bemerkenswertesten ist, dass sie keine Hashes speichern können, was die meisten Lockfile-Benutzer für unerlässlich halten.

Abhängigkeitsgruppen sind jedoch eine gültige Eingabe für Tools, die Lockfiles generieren. Darüber hinaus erlauben sowohl PDM als auch Poetry, einen Namen für eine Abhängigkeitsgruppe (innerhalb ihrer Vorstellung von Abhängigkeitsgruppen) zu verwenden, um sich auf seine gesperrte Variante zu beziehen.

Betrachten Sie daher ein Tool, das Lockfiles erzeugt, hier als $TOOL bezeichnet. Es könnte wie folgt verwendet werden

$TOOL lock --dependency-group=test
$TOOL install --dependency-group=test --use-locked

Alles, was ein solches Tool tun muss, ist sicherzustellen, dass seine Lockfile-Daten den Namen test aufzeichnen, um eine solche Verwendung zu unterstützen.

Die gegenseitige Kompatibilität von Abhängigkeitsgruppen ist nicht garantiert. Das Beispiel für Data Science oben zeigt beispielsweise widersprüchliche Versionen von scikit-learn. Daher kann die parallele Installation mehrerer gesperrter Abhängigkeitsgruppen erfordern, dass Tools zusätzliche Einschränkungen anwenden oder zusätzliche Lockfile-Daten generieren. Diese Probleme werden für diese PEP als außerhalb des Geltungsbereichs betrachtet.

Als zwei Beispiele dafür, wie Kombinationen gesperrt werden könnten

• Ein Tool könnte verlangen, dass Lockfile-Daten explizit für jede zu berücksichtigende gültige Kombination generiert werden.
• Poetry implementiert die Anforderung, dass alle Abhängigkeitsgruppen gegenseitig kompatibel sind, und generiert nur eine gesperrte Version. (Das bedeutet, es findet eine einzelne Lösung und nicht eine Menge oder Matrix von Lösungen.)

Eingaben für Umgebungsmanager

Eine gängige Verwendung in tox, Nox und Hatch ist die Installation einer Reihe von Abhängigkeiten in einer Testumgebung.

Zum Beispiel können unter tox.ini Typüberprüfungsabhängigkeiten direkt definiert werden.

[testenv:typing]
deps =
    pyright
    useful-types
commands = pyright src/

Diese Kombination bietet eine wünschenswerte Entwicklererfahrung in einem begrenzten Kontext. Unter dem entsprechenden Umgebungsmanager werden die für die Testumgebung benötigten Abhängigkeiten zusammen mit den Befehlen deklariert, die diese Abhängigkeiten benötigen. Sie werden nicht in Paketmetadaten veröffentlicht, wie es extras wären, und sie sind für das Tool, das sie zum Erstellen der relevanten Umgebung benötigt, auffindbar.

Abhängigkeitsgruppen gelten für solche Verwendungen, indem sie diese Anforderungsdaten effektiv von einem toolspezifischen Speicherort an einen breiter verfügbaren "anheben". Im obigen Beispiel hat nur tox Zugriff auf die deklarierte Liste von Abhängigkeiten. Unter einer Implementierung, die Abhängigkeitsgruppen unterstützt, könnten dieselben Daten in einer Abhängigkeitsgruppe verfügbar sein.

[dependency-groups]
typing = ["pyright", "useful-types"]

Die Daten können dann unter mehreren Tools verwendet werden. Beispielsweise könnte tox die Unterstützung als dependency_groups = typing implementieren und die obige deps-Verwendung ersetzen.

Damit Abhängigkeitsgruppen eine praktikable Alternative für Benutzer von Umgebungsmanagern darstellen, müssen die Umgebungsmanager die Verarbeitung von Abhängigkeitsgruppen ähnlich unterstützen, wie sie die direkte Deklaration von Abhängigkeiten unterstützen.

IDE und Editor-Nutzung von Anforderungsdaten

IDE- und Editor-Integrationen können von konventionellen oder konfigurierbaren Namensdefinitionen für Abhängigkeitsgruppen profitieren, die für Integrationen verwendet werden.

Es gibt mindestens zwei bekannte Szenarien, in denen es für einen Editor oder eine IDE von Vorteil ist, die nicht veröffentlichten Abhängigkeiten eines Projekts erkennen zu können.

• Testen: IDEs wie VS Code unterstützen grafische Benutzeroberflächen zum Ausführen bestimmter Tests.
• Linting: Editoren und IDEs unterstützen oft Linting- und Autoformatierungs-Integrationen, die Fehler hervorheben oder korrigieren.

Diese Fälle könnten durch die Definition konventioneller Gruppennamen wie test, lint und fix oder durch die Definition von Konfigurationsmechanismen, die die Auswahl von Abhängigkeitsgruppen ermöglichen, behandelt werden.

Zum Beispiel deklariert die folgende pyproject.toml die drei oben genannten Gruppen.

[dependency-groups]
test = ["pytest", "pytest-timeout"]
lint = ["flake8", "mypy"]
fix = ["black", "isort", "pyupgrade"]

Diese PEP unternimmt keinen Versuch, solche Namen zu standardisieren oder sie für solche Zwecke zu reservieren. IDEs können standardisieren oder Benutzern erlauben, die für verschiedene Zwecke verwendeten Gruppennamen zu konfigurieren.

Diese Deklaration ermöglicht es, dass das Wissen des Projektverfassers über die geeigneten Tools für das Projekt mit allen Bearbeitern dieses Projekts geteilt wird.