PEP Status

Nachdem dieser PEP zunächst entworfen wurde, wurde PEP 508 entwickelt und eingereicht, um die Syntax der Abhängigkeitsdeklaration, einschließlich Umgebungsmarkierungen, vollständig zu spezifizieren. Infolgedessen wurde dieser PEP zugunsten des umfassenderen PEP 508 abgelehnt.

Zusammenfassung

Eine Umgebungsmarkierung beschreibt eine Bedingung bezüglich der aktuellen Ausführungsumgebung. Sie werden verwendet, um anzuzeigen, wann bestimmte Abhängigkeiten nur in bestimmten Umgebungen erforderlich sind, und um unterstützte Plattformen für Distributionen mit zusätzlichen Einschränkungen über die Verfügbarkeit einer Python-Laufzeitumgebung hinaus anzugeben.

Umgebungsmarkierungen wurden erstmals in PEP 345 spezifiziert. PEP 426 (der PEP 345 ersetzen würde) schlug Erweiterungen für die Markierungen vor. Als 2.7.10 veröffentlicht wurde, reichten selbst diese Erweiterungen aufgrund ihrer Abhängigkeit von einfachen lexikalischen Vergleichen nicht mehr aus, und so wurde dieser PEP ins Leben gerufen.

Begründung

Viele Python-Pakete werden mit Blick auf Portabilität geschrieben.

Für viele Pakete bedeutet dies, dass sie darauf abzielen, eine breite Palette von Python-Versionen zu unterstützen. Wenn sie von Bibliotheken wie argparse abhängen – die als externe Bibliotheken begannen, aber später in den Kern integriert wurden – ist die Angabe eines einzigen Satzes von Anforderungen schwierig, da sich der Satz der erforderlichen Pakete je nach verwendeter Python-Version unterscheidet.

Für andere Pakete bedeutet die Entwicklung auf Portabilität die Unterstützung mehrerer Betriebssysteme. Die erheblichen Unterschiede zwischen ihnen können jedoch bedeuten, dass bestimmte Abhängigkeiten nur auf bestimmten Plattformen benötigt werden (z. B. Abhängigkeit von pywin32 nur unter Windows).

Umgebungsmarkierungen versuchen, mehr Flexibilität in einer Liste von Anforderungen zu bieten, indem sie es dem Entwickler ermöglichen, Anforderungen aufzulisten, die für eine bestimmte Umgebung spezifisch sind.

Beispiele

Hier sind einige Beispiele für solche Markierungen in einer requirements.txt:

pywin32 >=1.0 ; sys_platform == 'win32'
unittest2 >=2.0,<3.0 ; python_version == '2.4' or python_version == '2.5'
backports.ssl_match_hostname >= 3.4 ; python_version < '2.7.9' or (python_version >= '3.0' and python_version < '3.4')

Und hier ist ein Beispiel für Metadaten, die bedingt in setup.py für eine Distribution enthalten sind, die PyWin32 sowohl zur Laufzeit als auch zur Build-Zeit unter Windows benötigt:

setup(
  install_requires=["pywin32 > 1.0 : sys.platform == 'win32'"],
  setup_requires=["pywin32 > 1.0 : sys.platform == 'win32'"]
  )

Mikrosprache

Die Mikrosprache dahinter ist wie folgt. Sie vergleicht:

• Zeichenketten mit den Operatoren == und in (und ihren Gegenteilen)
• Versionsnummern mit den Operatoren <, <=, >= und < zusätzlich zu denen, die für Zeichenketten unterstützt werden.

Die üblichen booleschen Operatoren and und or können zur Kombination von Ausdrücken verwendet werden, und Klammern sind für die Gruppierung zulässig.

Die Pseudo-Grammatik ist:

MARKER: EXPR [(and|or) EXPR]*
EXPR: ("(" MARKER ")") | (STREXPR|VEREXPR)
STREXPR: STRING [STRCMPOP STREXPR]
STRCMPOP: ==|!=|in|not in
VEREXPR: VERSION [VERCMPOP VEREXPR]
VERCMPOP: (==|!=|<|>|<=|>=)

SUBEXPR ist entweder eine Python-Zeichenkette (wie 'win32') oder eine der unten aufgeführten Strings Marker-Variablen.

VEREXPR ist ein PEP 440 Versionsbezeichner oder eine der unten aufgeführten Marker-Variablen für Version number. Vergleiche zwischen Versionsnummern erfolgen nach PEP 440 Semantik.

def format_full_version(info):
    version = '{0.major}.{0.minor}.{0.micro}'.format(info)
    kind = info.releaselevel
    if kind != 'final':
        version += kind[0] + str(info.serial)
    return version

python_full_version = format_full_version(sys.version_info)
implementation_version = format_full_version(sys.implementation.version)

Urheberrecht

Dieses Dokument wurde gemeinfrei erklärt.