Python-Module (Referenzhandbuch zu GNU Guix)

22.8.8 Python-Module

Zurzeit stellen wir ein Paket für Python 2 und eines für Python 3 jeweils über die Scheme-Variablen mit den Namen python-2 und python zur Verfügung, entsprechend der Erklärungen im Abschnitt Versionsnummern. Um Verwirrungen und Namenskollisionen mit anderen Programmiersprachen zu vermeiden, erscheint es als wünschenswert, dass der Name eines Pakets für ein Python-Modul auch das Wort python enthält.

Manche Module sind nur mit einer Version von Python kompatibel, andere mit beiden. Wenn das Paket Foo mit Python 3 kompiliert wird, geben wir ihm den Namen python-foo. Wenn es mit Python 2 kompiliert wird, wählen wir den Namen python2-foo. Wir sind dabei, Python-2-Pakete aus der Distribution zu entfernen; bitte reichen Sie keine neuen Python-2-Pakete mehr ein.

Wenn ein Projekt bereits das Wort python im Namen hat, lassen wir es weg; zum Beispiel ist das Modul python-dateutil unter den Namen python-dateutil und python2-dateutil verfügbar. Wenn der Projektname mit py beginnt (z.B. pytz), behalten wir ihn bei und stellen das oben beschriebene Präfix voran.

Anmerkung: Im Moment sind gleich zwei verschiedene Erstellungssysteme für Python-Pakete in Guix in Umlauf: python-build-system und pyproject-build-system. Lange Zeit hat man sein Python-Paket aus einer Datei setup.py heraus erstellt, deren gewachsene Struktur nicht formell festgelegt war. Das lief überraschend gut, wenn man sich den Erfolg von Python anschaut, allerdings ließen sich nur schwer Werkzeuge zur Handhabung schreiben. Daraus ergab sich eine Vielzahl alternativer Erstellungssysteme, bis sich die Gemeinschaft auf einen formellen Standard zum Festlegen der Erstellungsanforderungen geeinigt hatte. pyproject-build-system ist die Implementierung dieses Standards in Guix. Wir stufen es als „experimentell“ ein, insofern als dass es noch nicht all die Build Backends für PEP-517 unterstützt. Dennoch würden wir es begrüßen, wenn Sie es für neue Python-Pakete verwenden und Probleme melden würden. Schlussendlich wird es für veraltet erklärt werden und in python-build-system aufgehen.

Abhängigkeiten angeben

22.8.8.1 Abhängigkeiten angeben

Informationen über Abhängigkeiten von Python-Paketen, welche mal mehr und mal weniger stimmen, finden sich normalerweise im Verzeichnisbaum des Paketquellcodes: in der Datei pyproject.toml, der Datei setup.py, in requirements.txt oder in tox.ini (letztere beherbergt hauptsächlich Abhängigkeiten für Tests).

Wenn Sie ein Rezept für ein Python-Paket schreiben, lautet Ihr Auftrag, diese Abhängigkeiten auf angemessene Arten von „Eingaben“ abzubilden (siehe Eingaben). Obwohl der pypi-Importer hier normalerweise eine gute Arbeit leistet (siehe guix import aufrufen), könnten Sie die folgende Prüfliste durchgehen wollen, um zu bestimmen, wo welche Abhängigkeit eingeordnet werden sollte.

Derzeit ist unser Python-Paket so geschrieben, dass es setuptools und pip mitinstalliert. Das wird sich bald ändern und wir möchten unseren Nutzern nahelegen, für Python-Entwicklungsumgebungen python-toolchain zu verwenden.
guix lint wird Sie mit einer Warnung darauf aufmerksam machen, wenn setuptools oder pip zu den nativen Eingaben hinzugefügt wurden, weil man im Allgemeinen keines der beiden anzugeben braucht.
Python-Abhängigkeiten, die zur Laufzeit gebraucht werden, stehen im propagated-inputs-Feld. Solche werden typischerweise mit dem Schlüsselwort install_requires in setup.py oder in der Datei requirements.txt definiert.
Python-Pakete, die nur zur Erstellungszeit gebraucht werden – z.B. jene, die in pyproject.toml unter build-system.requires stehen oder die mit dem Schlüsselwort setup_requires in setup.py aufgeführt sind – oder Abhängigkeiten, die nur zum Testen gebraucht werden – also die in tests_require oder in der tox.ini –, schreibt man in native-inputs. Die Begründung ist, dass (1) sie nicht propagiert werden müssen, weil sie zur Laufzeit nicht gebraucht werden, und (2) wir beim Cross-Kompilieren die „native“ Eingabe des Wirtssystems wollen.
Beispiele sind die Testrahmen pytest, mock und nose. Wenn natürlich irgendeines dieser Pakete auch zur Laufzeit benötigt wird, muss es doch in propagated-inputs stehen.
Alles, was nicht in die bisher genannten Kategorien fällt, steht in inputs, zum Beispiel Programme oder C-Bibliotheken, die zur Erstellung von Python-Paketen mit enthaltenen C-Erweiterungen gebraucht werden.
Wenn ein Python-Paket optionale Abhängigkeiten hat (extras_require), ist es Ihnen überlassen, sie hinzuzufügen oder nicht hinzuzufügen, je nachdem wie es um deren Verhältnis von Nützlichkeit zu anderen Nachteilen steht (siehe guix size).