Univention Bugzilla – Bug 22521
Python-Modul-Abhängigkeit und __init__.py Datei
Last modified: 2012-07-05 15:07:49 CEST
Beim Bau von univention-config-registry tritt das Problem auf, das zum Bauzeitpunkt univention-install-config-registry selbst aufgerufen wird. Da das Bestandteil vom ucr-Paket selbst ist, wird PYTHONPATH=python gesetzt und das Programm lokal ausgeführt. Damit das aber funktioniert muß in python/ eine Datei __init__.py vorhanden sein. Diese überschreibt allerdings die global Datei aus python-univention, was auch dazu führt, daß python-univention-lib nicht mehr verfügbar ist. Als Workaround verwendet jetzt univention.config_registry folgenden Hack, was für die Installation reicht, da dort die Funktion nicht benötigt wird: +try: + from univention.lib.shell import escape_value +except ImportError: + def escape_value(v): sys.exit(1) # FIXME: univention.lib clashed during install Insgesammt muß aber dingend folgendes geklärt werden: 1. Welches Paket bring univention/__init__.py mit? (derzeit python-univention) 2. In welchem Verhältnis stehen python-univention und python-univention-lib? 3. Kann jedes beliebige Paket weitere Module unter univention/ installieren oder sollte jedes Paket ein eigenes Unterverzeichnis darin anlegen? 4. Lassen sich mehrere Zweige per PYTHONPATH mergen, d.h. kann ein noch nicht installiertes Paket wie ucr zum Build-Zeitpunkt die Modul-Hierarchie erweitern? 5. Bei den Modulen sollte auf (zyklische) Inter-Modul-Abhängigkeit geschaut werden: Einige Module in pyhon-univention und python-univention-lib importieren z.B. univention.config_registry, aber u.cr selbst benötigt univention.lib.shell
Durch den Workaround ist der Fix zur 3.0 nicht zwingend, richtig? (In reply to comment #0) > Insgesammt muß aber dingend folgendes geklärt werden: > > 1. Welches Paket bring univention/__init__.py mit? (derzeit python-univention) Ich denke das sollte auch so bleiben. > 2. In welchem Verhältnis stehen python-univention und python-univention-lib? Das stimmt, eigentlich sind die Pakete identisch. > 3. Kann jedes beliebige Paket weitere Module unter univention/ installieren > oder sollte jedes Paket ein eigenes Unterverzeichnis darin anlegen? Eigene Unterverzeichnisse halte ich für besser. Für UCR wäre dann auch univention/config/registry.py besser gewesen. > 4. Lassen sich mehrere Zweige per PYTHONPATH mergen, d.h. kann ein noch nicht > installiertes Paket wie ucr zum Build-Zeitpunkt die Modul-Hierarchie erweitern? > > 5. Bei den Modulen sollte auf (zyklische) Inter-Modul-Abhängigkeit geschaut > werden: Einige Module in pyhon-univention und python-univention-lib importieren > z.B. univention.config_registry, aber u.cr selbst benötigt univention.lib.shell Ich denke UCR darf die lib.shell nicht verwenden.
(In reply to comment #1) > > 2. In welchem Verhältnis stehen python-univention und python-univention-lib? > > Das stimmt, eigentlich sind die Pakete identisch. Wir belassen die Aufteilung im Moment so. > > 3. Kann jedes beliebige Paket weitere Module unter univention/ installieren > > oder sollte jedes Paket ein eigenes Unterverzeichnis darin anlegen? > > Eigene Unterverzeichnisse halte ich für besser. Für UCR wäre dann auch > univention/config/registry.py besser gewesen. Aus python-univention-lib wurden jetzt Module herausgezogen, die Abhängigkeiten auf andere UCS Pakete benötigt haben. Beispielsweise UDM oder policy_result. univention-directory-management-modules und univention-policy bringt jetzt python Dateien für univention.lib mit. > > 4. Lassen sich mehrere Zweige per PYTHONPATH mergen, d.h. kann ein noch nicht > > installiertes Paket wie ucr zum Build-Zeitpunkt die Modul-Hierarchie erweitern? > > > > 5. Bei den Modulen sollte auf (zyklische) Inter-Modul-Abhängigkeit geschaut > > werden: Einige Module in pyhon-univention und python-univention-lib importieren > > z.B. univention.config_registry, aber u.cr selbst benötigt univention.lib.shell > > Ich denke UCR darf die lib.shell nicht verwenden. Das sollte durch den Punkt oben jetzt behoben sein, zumindest auf Python Ebene.
Ist angepasst \item The module \ucsName{policy\_result.py} has been moved to \ucsName{univention-policy-tools} (\ucsBug{22521}).
(In reply to comment #3) > Ist angepasst > > \item The module \ucsName{policy\_result.py} has been moved to > \ucsName{univention-policy-tools} (\ucsBug{22521}). root@master:/usr/share/pyshared/univention/lib# dpkg -S /usr/share/pyshared/univention/lib/policy_result.py univention-policy-tools: /usr/share/pyshared/univention/lib/policy_result.py Ist umgezogen. ChangeLog existiert.
UCS 3.0-0 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte dieser Bug dupliziert werden: "Clone This Bug"