Wie können Sie Build-Time-Abhängigkeiten deklarieren, ohne andere Pakete zu beschädigen?

8

Ich habe ein Problem bei der Installation eines Pakets festgestellt, das von python-daemon abhängig war. Letztendlich habe ich es auf die neueste Version des gestern veröffentlichten Pakets python-daemon (2.0.3) zurückverfolgt. Testen in einer virtuellen Umgebung auf einem Ubuntu 14.04-Rechner und Ausgeben der folgenden Befehle:

%Vor%

Also die Installation von python-daemon schien zu funktionieren, aber etwas betroffen pip oder setuptools , weil andere Pakete ( celery , flask ), ich versuche mit pip zu installieren, nachdem dies die gleiche traceback gibt:

%Vor%

Wenn ich Python-Daemon mit pip-Dingen wieder deinstalliere und Pakete, die nicht installiert wurden, installieren Sie jetzt. Ist jemand anderes mit einem anderen Projekt auf etwas Ähnliches gestoßen? Meine Lösung war, die vorherige Version zu pipen

%Vor%

fragte sich aber, was einen solchen Fehler verursachen könnte.

    
Paul Joireman 15.01.2015, 20:24
quelle

1 Antwort

4

(Dieses Verhalten wurde in Python-Daemon Version 2.0.4 und höher korrigiert.)

Dafür gibt es zwei Seiten:

  • Setuptools geht davon aus, dass es das Zentrum von allem ist.
  • Version 2.0.3 von python-daemon berücksichtigt das nicht.

Eine ausführlichere Erklärung: Es gibt einen komplexen Code, der Docutils verwendet, die am Prozess python-daemon build beteiligt sind, der nach der Installation nicht benötigt wird und nicht Teil des Bibliothekscodes ist.

Es ist zu komplex, um in dem nicht importierbaren (und daher nicht testbaren) setup.py zu belassen, so dass der Build-Code zu einem separaten testbaren Modul, version (in der Datei version.py ), weitergeleitet wird. die selbst Docutils verwendet.

Aber dann hat die setup.py eine zirkuläre Abhängigkeit: Wie importiert version , wenn Docutils noch nicht installiert ist? Wie man Setuptools verwendet, um sicherzustellen, dass Docutils installiert ist, wenn setup.py zum Abschluss ausgeführt wird, muss version ? Alle möglichen Lösungen sind hässlich und verwirrend.

Der Ansatz von 'python-daemon' 2.0.3 besteht darin, Docutils für die Einrichtung zu deklarieren und ein Setuptools Einstiegspunkt für die Arbeit, die version benötigt. Auf diese Weise kann setup.py Docutils vor einem der Einstiegspunkte installieren, die version verwenden.

Aber jetzt kommen wir zu dem ersten Punkt, dass sich Setuptools als das Zentrum von allem anmaßt. Durch das Deklarieren eines Einstiegspunkts hat setup.py danach jede Setuptools-Aktion geändert, und jedes Paket schlägt fehl, wenn es die Einstiegspunkte nicht finden kann. Und da die meisten von ihnen nicht version oder die angegebenen Funktionen in diesem Modul haben, stürzen sie Setuptools.

Was im Wesentlichen ein Bug ist, der behoben werden muss, zeigt einen nicht verstandenen Eckfall in Setuptools. Ich stimme also Ihre Frage ab.

Es scheint keine gute Lösung dafür zu geben: Module für setup.py verfügbar zu haben, aber sicherzustellen, dass die Anforderungen zuerst erfüllt werden. Setuptools geht davon aus, dass es das einzige Build-System ist, das benötigt wird, um alle Abhängigkeiten für alles zu erfüllen, und wenn diese Annahme fehlschlägt, ist es sehr schwierig, herumzukommen.

Danke an die Python Packaging Authority und die distutils-sig forum , um mir das zu erklären.

    
bignose 20.01.2015, 22:23
quelle

Tags und Links