[Python-de] Programme aus mehreren Modulen

Ulrich Berning ulrich.berning at t-online.de
Die Feb 17 01:53:43 CET 2004


Stefan Schwarzer schrieb:

>Hallo Matthias,
>
>On Mon, 2004-02-16 21:08:44 +0100, Matthias Kluwe wrote:
>  
>
>>Ich mache mir bereits seit längerem Gedanken darüber, was wohl "Der
>>Richtige" Weg ist, Programme, die aus mehreren Modulen bestehen,
>>auszuliefern, bin aber zu keinem vernünftigen Ergebnis gekommen.
>>
>>Folgende Situation sei gegeben: Ein als "Hauptprogramm" zu startendes
>>Modul (z.B. "app.py") und weitere Module, die von diesem benötigt
>>werden.
>>    
>>
>
>ich denke, der heutzutage übliche (ob "richtige", vermag ich nicht zu
>sagen) Weg ist:
>
>- ein Distutils-Archiv des Python-Codes erstellen
>  
>- dieses unterhalb von site-packages installieren (lassen)
>
>- nur Programme, die tatsächlich unmittelbar auszuführen sind - per
>  Distutils - nach /usr/local/bin (oder entsprechendes) kopieren
>
>- die genannten Programme verwenden
>
>  from paketname import modul
>  
>  wenn das Verzeichnis unter site-packages paketname heißt, um auf die
>  neu installierten Module zuzugreifen
>
>Viele Grüße
> Stefan
>
>_______________________________________________
>python-de maillist  -  python-de at python.net
>http://python.net/mailman/listinfo/python-de
>
>  
>
Nach mehreren Jahren Erfahrung mit kommerziellen Python-Applikationen 
kann ich ich nur davon abraten, Anwendungs-Module in site-packages zu 
installieren:

1.) Die Pfade werden ziemlich lang. Erzähl deinem Kunden mal, er soll 
mal eben einen Parameter in dem Konfigurations-Modul 
/usr/local/lib/python2.3/site-packages/my_application/common/config.py 
ändern. Er wird sich bedanken und Du vergeudest Deine Zeit am Telefon 
mit dem Buchstabieren von Verzeichnisnamen. Das habe ich alles im Laufe 
der ersten Jahre alles erlebt.

2.) Indem man eine Applikation in das site-packages Verzeichnis einer 
bestimmten Python-Version installiert, binden man die Applikation an 
diese Version. Wenn  ich den Python-Quellcode ausliefere (was wir heute 
allerdings nicht mehr machen), muss ich bei jeder neuen Python-Version 
die Applikation neu installieren (oder kopieren) wo ein compileall 
(evtl. verpackt in ein Shell-Script) genügt hätte.

3.)  Die Applikation, die aus Start-Script, Modulen und evtl. vielen 
weiteren Dateien (Konfigurationen, Grafiken, Text-Dateien usw.) besteht, 
wird im System verstreut: Module in site-packages, Start-Script in 
irgendeinem bin Verzeichnis, alles andere irgendwo im System. Wir haben 
die besten Erfahrungen damit gemacht, wenn die Applikation komplett in 
einem Verzeichnis liegt, das dann durch Unterverzeichnisse logisch und 
durch den Entwickler vorgegeben strukturiert ist (bin, doc, modules, 
images, config, ...). Das Start-Script wird mit einem symbolischen Link 
in /usr/bin oder /usr/local/bin ohne Pfad-Erweiterungen sofort 
aufrufbar. Unter Windows wird das in der Regel durch eine Verknüpfung im 
Windows-Startmenü erledigt.
Seine Module findet die Anwendung entweder durch eine Umgebungs-Variable 
(bzw. Registry-Eintrag unter Windows), die auf das Haupt-Verzeichnis der 
Anwendung zeigt (z.B. $FOO_HOME für die Applikation foo), oder durch 
relative Pfade ausgehend vom Pfad des Start-Scripts. Im Start-Script 
wird sys.path dann entsprechend erweitert.

4.) Wenn site-packages für Applikationen gedacht worden wäre, würde es 
dann nicht application-packages oder app-packages lauten? :-)
Meines Erachtens ist site-packages eher ein Verzeichnis, in dem ich 
mehrfach verwendbare Module oder Packages installieren kann, die nicht 
zum Standard-Umfang von Python gehören. Eine Art Bibliotheks-Verzeichnis 
eben.


Grüße
Ulli