[Python-de] CI: req.txt und PIP_INDEX_URL

[Christopher Arndt]

> Am 22.03.2017 um 17:44 schrieb Thomas Güttler <guettliml at thomas-guettler.de>:
> 
> Per PIP_INDEX_URL habt für verschiedene pypi-Server, und einen anderen Paket-Stand. OK, interessant.
> 
> Macht das nicht viel Aufwand diese verschiedenen pypi-Server mit den passenden Paketen zu versorgen?

Mit Devpi kann man auf einem Server verschiedene Paketindexe haben, die von einander ableiten. Wir haben eine Paketindex für die Pakete der Produktionsumgebung (der auch aus der DMZ erreichbar ist)  und einen Paketindex für die Development/Integration/Staging-Umgebung, der nur im lokalen Netz erreichbar ist. Der Dev-Index leitet vom Prod-Index ab, d.h. Er ist sozusagen ein Proxy: wenn Pakete nicht im Dev-Index sind, werden sie vom Prod-Index geholt. Aber man kann auf den Dev-Index neuere Paketversionen hochladen, die im Prod-Index nicht sichtbar sind. Außerdem können auf dem Dev-Index Paketversionen und deren Files überschrieben werden, während auf dem Prod-Index bei jeder Änderung eine neue Paketversion hochgeladen werden muss, er ist also nicht-volatil (Stichwort: Rollback).

In der Praxis wird also einfach eine neue Version eines Paktes zuerst auf den Dev-Index hochgeladen und - wenn alles funktioniert - mit einem Befehl auf den Prod-Index gepusht.

Zusätzlich kann jeder Entwickler noch einen eigenen Paketindex haben, aber das nur nebenbei.

> Eine Frage zu "-r{toxinidir}/requirements/dev.txt": Sind die Paketversionen in dieser Datei gepinnt (also mit exakter Version zB ==a.b.c)?

In einer idealen Welt: ja ;)

In der Praxis sind wir leider erst dabei, das in allen Projekten Schritt für Schritt wirklich streng durchzusetzen. Momentan haben wir leider in vielen Projekten noch nur Versionsbeschränkungen (>=a.b,<c.d) in den Requirements-Dateien.

> > Falls ja, wie wird diese Datei aktualisiert?

Ich bin gerade dabei in unserem größten Projekt die Erzeugung der Requirements-Dateien aus Vorlagen mit pip-compile (pip-tools) einzuführen. Allein durch diesen Prozess sind schon etliche Dependency-Konflikte aufgefallen, die vorher unbemerkt blieben. Insbesondere in die Requirements fürs Development (Tests, Doc-Erzeugung usw.) schleichen sich schnell Dependencies ein, die wiederum andere Dependencies nach sich ziehen, die mit den Paketversionen, die für Produktionsumgebung gepinnt sind, im Konflikt stehen.

Es muss sich noch zeigen, ob der Weg mit pip-tools praktikabel ist, leider gibt es immer noch zu viele Pakete, die in ihrer setup.py irgendwelche Dependencies fest auf eine Version pinnen, obwohl dies eigentlich gar nicht nötig wäre, oder gar einfach ihre requirements.txt unverändert in die install_requires in der setup.py übernehmen. Die meisten Paketautoren sind sich wahrscheinlich gar nicht bewusst, dass sie damit bei Anwendungen, die ihre Pakete und noch andere Dependencies verwenden, die dies genauso machen, Versions-Konflikte heraufbeschwören.

Aber wenn man einmal eine Vorlage für die Requirements hat, aus der sich eine funktionierende Requirements-Datei erstellen lässt, kann man diese mit pip-compile leicht aktualisieren und merkt dann sofort, wenn eine neue Version eines Pakets Versionskonflikte mit einer anderen Dependency mit sich bringt.

-- 
Christopher Arndt <info at chrisarndt.de>