Wie Python-GUI-Applikationen im Dateisystem organisieren

05/08/2008 - 16:26 von mark.asbach | Report spam
Hallo Python-GUI-Programmierer,

meine Frage ist im Subject vielleicht etwas schwammig formuliert: Ich
würde gerne ein Python Applikation so strukturieren, dass es am meisten
Sinn macht. Ich arbeite unter Linux / Unix, d.h. die Applikation soll
über ein einzelnes Skript zu starten sein. Allerdings braucht so eine
Applikation ja auch noch eine Menge an Support-Files wie icons,
wx-Widget Ressourcen, etc. und ich würde sie zudem gerne in mehrere
Python-Module innerhalb einer Package aufteilen.

Bislang sieht das ungefàhr so aus:

Source/segmentviewer/classes/application.py
Source/segmentviewer/classes/printing.py
Source/segmentviewer/classes/fileformat.py
Source/segmentviewer/ressources/main_window.wxg
Source/segmentviewer/ressources/icon.png
Source/segmentviewer/segmentviewer.py

Das Problem ist nun, dass ich gerne mit 'segmentviewer' die Applikation
starten würde, d.h. ein gleichnamiges Skript muss nach $prefix/bin
installiert werden, die restlichen Python-Dateien sollten natürlich nach
$prefix/lib/python-2.5/site-packages/segmentviewer/ o.à. und die
Ressourcen vermutlich nach $prefix/share .

Daraus ergeben sich ein paar Fragen:
- Wie würde man sinnvollerweise das Python-Package nennen?
- Sie hat ja eigentlich für andere Applikationen keinen Nutzen - liegt
sie da richtig in den site-packages?
- Wie kommt man zur Laufzeit an den Pfad wo die Ressourcen sind?
- Wenn die Package mit den Klassen bereits 'segmentviewer' (statt
'classes') heißt, kann ich kein gleichnamiges Start-Skript in meinem
Quellcode-Baum haben. Wie würde man den organisieren?

Würde mich über ein paar Tipps freuen. Ein Hinweis auf eine gut
strukturierte Python Applikation bei der ich abgucken kann, wàre auch
sehr hilfreich.

Ach so, die Applikation ist Teil eines größeren Projekts und ist daher
in einem Autotools Quelltext-Baum untergebracht.

Vielen Dank im Voraus,
Mark
 

Lesen sie die antworten

#1 Diez B. Roggisch
05/08/2008 - 16:29 | Warnen spam
Mark Asbach wrote:

Hallo Python-GUI-Programmierer,

meine Frage ist im Subject vielleicht etwas schwammig formuliert: Ich
würde gerne ein Python Applikation so strukturieren, dass es am meisten
Sinn macht. Ich arbeite unter Linux / Unix, d.h. die Applikation soll
über ein einzelnes Skript zu starten sein. Allerdings braucht so eine
Applikation ja auch noch eine Menge an Support-Files wie icons,
wx-Widget Ressourcen, etc. und ich würde sie zudem gerne in mehrere
Python-Module innerhalb einer Package aufteilen.

Bislang sieht das ungefàhr so aus:

Source/segmentviewer/classes/application.py
Source/segmentviewer/classes/printing.py
Source/segmentviewer/classes/fileformat.py
Source/segmentviewer/ressources/main_window.wxg
Source/segmentviewer/ressources/icon.png
Source/segmentviewer/segmentviewer.py

Das Problem ist nun, dass ich gerne mit 'segmentviewer' die Applikation
starten würde, d.h. ein gleichnamiges Skript muss nach $prefix/bin
installiert werden, die restlichen Python-Dateien sollten natürlich nach
$prefix/lib/python-2.5/site-packages/segmentviewer/ o.à. und die
Ressourcen vermutlich nach $prefix/share .

Daraus ergeben sich ein paar Fragen:
- Wie würde man sinnvollerweise das Python-Package nennen?
- Sie hat ja eigentlich für andere Applikationen keinen Nutzen - liegt
sie da richtig in den site-packages?



Ja, warum nicht?

- Wie kommt man zur Laufzeit an den Pfad wo die Ressourcen sind?
- Wenn die Package mit den Klassen bereits 'segmentviewer' (statt
'classes') heißt, kann ich kein gleichnamiges Start-Skript in meinem
Quellcode-Baum haben. Wie würde man den organisieren?

Würde mich über ein paar Tipps freuen. Ein Hinweis auf eine gut
strukturierte Python Applikation bei der ich abgucken kann, wàre auch
sehr hilfreich.

Ach so, die Applikation ist Teil eines größeren Projekts und ist daher
in einem Autotools Quelltext-Baum untergebracht.



setuptools hilft. Damit kannst du entry_points vom typ script generieren,
die dann unter $prefix/bin ein start-script automatisch anlegen.

UNd mit den dazugehoerigen pkg_resources greifst du auf die resourcen zu -
die du einfach in den packages belaesst, so wie jetzt. Einen grund das
aufzuteilen sehe ich nicht.

Diez

Ähnliche fragen