20.4.7 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. Pakete sollten dann hinzugefügt werden, wenn sie gebraucht werden. Wir erstellen keine Python-2-Varianten von Paketen, wenn wir sie nicht benutzen wollen.

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.

20.4.7.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 setup.py, in requirements.txt oder in tox.ini.

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 Aufruf von guix import), könnten Sie die folgende Prüfliste durchgehen wollen, um zu bestimmen, wo welche Abhängigkeit eingeordnet werden sollte.

• Derzeit ist unser Python-2-Paket so geschrieben, dass es setuptools und pip installiert, wie es auch in den Vorgaben zu Python 3.4 gemacht wird. Sie müssen also keines der beiden als Eingabe angeben. Wenn Sie es doch tun, wird guix lint Sie darauf mit einer Warnung aufmerksam machen.
• 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 mit dem Schlüsselwort setup_requires in setup.py aufgeführt sind — oder die nur zum Testen gebraucht werden — also die in tests_require —, stehen 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).