Re: [Python-de] setuptools installieren keine data files
On 27.06.06 13:29:48, Diez B. Roggisch wrote:
Wahrscheinlich ist 'ui' kein Package (__init__.py).
Richtig, kein __init__.py, aber auch mit keinerlei .ui-Files im egg oder unter <PYTHONHOME>/share/
Was Stefan meinte war: das muss ein package sein - also ein (leeres) __init__.py haben.
Hab ich mich unklar ausgedrueckt? Was ich meinte war: Ja, da war kein __init__.py drin, aber auch nach einem touch ui/__init__.py fuehrt ein python setup.py install zu keinerlei "Verwendung" der .ui-Dateien, weder unterhalb von build, noch in <PYTHONHOME> oder im (ausgepackten) egg. Was mir grad noch auffiel, ein python setup.py install_data fuehrt zu: andreas@morpheus:~/projects/xpathevaluator>python setup.py install_data running install_data Traceback (most recent call last): File "setup.py", line 42, in ? package_data = { File "/home/andreas/python2.4/lib/python2.4/distutils/core.py", line 149, in setup dist.run_commands() File "/home/andreas/python2.4/lib/python2.4/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/home/andreas/python2.4/lib/python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/home/andreas/python2.4/lib/python2.4/distutils/command/install_data.py", line 50, in run for f in self.data_files: TypeError: iteration over non-sequence Andreas -- Are you ever going to do the dishes? Or will you change your major to biology? _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Hab ich mich unklar ausgedrueckt?
Ja.
Was ich meinte war: Ja, da war kein __init__.py drin, aber auch nach einem touch ui/__init__.py fuehrt ein python setup.py install
zu keinerlei "Verwendung" der .ui-Dateien, weder unterhalb von build, noch in <PYTHONHOME> oder im (ausgepackten) egg.
Was mir grad noch auffiel, ein python setup.py install_data fuehrt zu: andreas@morpheus:~/projects/xpathevaluator>python setup.py install_data running install_data Traceback (most recent call last): File "setup.py", line 42, in ? package_data = { File "/home/andreas/python2.4/lib/python2.4/distutils/core.py", line 149, in setup dist.run_commands() File "/home/andreas/python2.4/lib/python2.4/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/home/andreas/python2.4/lib/python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/home/andreas/python2.4/lib/python2.4/distutils/command/install_data.py", line 50, in run for f in self.data_files: TypeError: iteration over non-sequence
Du musst eine Liste von Dateiendungen angeben. Angehangen ein mini-projekt das klappt. Diez _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
On 27.06.06 16:11:21, Diez B. Roggisch wrote:
Was ich meinte war: Ja, da war kein __init__.py drin, aber auch nach einem touch ui/__init__.py fuehrt ein python setup.py install
zu keinerlei "Verwendung" der .ui-Dateien, weder unterhalb von build, noch in <PYTHONHOME> oder im (ausgepackten) egg.
Was mir grad noch auffiel, ein python setup.py install_data fuehrt zu: andreas@morpheus:~/projects/xpathevaluator>python setup.py install_data running install_data Traceback (most recent call last): File "setup.py", line 42, in ? package_data = { File "/home/andreas/python2.4/lib/python2.4/distutils/core.py", line 149, in setup dist.run_commands() File "/home/andreas/python2.4/lib/python2.4/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/home/andreas/python2.4/lib/python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/home/andreas/python2.4/lib/python2.4/distutils/command/install_data.py", line 50, in run for f in self.data_files: TypeError: iteration over non-sequence
Du musst eine Liste von Dateiendungen angeben. Angehangen ein mini-projekt das klappt.
Das hatte ich schon, was aber fehlte war die Nennung des Packages "ui" in der Liste der packages... Hmm, aber irgendwie ist das nicht das was ich wollte, die ui-Dateien sollten in eigentlich nicht ins egg, sondern nach PYTHONHOME/share/<appname>. Sonst muss ich ja bei der Paketierung fuer Debian wieder "Verrenkungen" anstellen. Ausserdem hab ich auch noch Uebersetungsdateien die passend installiert werden muessen (die duerfen nicht ins egg)... Ich glaube ich eroeffne dafuer lieber nen neuen Thread... Andreas -- You look tired. _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Das hatte ich schon, was aber fehlte war die Nennung des Packages "ui" in der Liste der packages...
Was für eine Nennung? package_data = { # If any package contains files, include them '': ['*.ui'], } inkludiert alle *ui-files aus welchem Package auch immer.
Hmm, aber irgendwie ist das nicht das was ich wollte, die ui-Dateien sollten in eigentlich nicht ins egg, sondern nach PYTHONHOME/share/<appname>. Sonst muss ich ja bei der Paketierung fuer Debian wieder "Verrenkungen" anstellen. Ausserdem hab ich auch noch Uebersetungsdateien die passend installiert werden muessen (die duerfen nicht ins egg)...
Ich arbeite unter Debian - und ich habe keine Verrenkungen. Wenn man mittels des im ersten meiner Postings beschriebenen resource managers auf die Dateien zugreift, ist alles was man angibt das Package & der Filename. Wenn das in einem Egg ist, dann wird es daraus sogar extrahiert (da egg ja gezippt und direkter File-access so nicht geht)- und im Sinne einer sauberen Installation sind eggs sicherlich vorzuziehen. Denn die kann man als Ganzes löschen, statt mühselig nach rumfliegenden Müll in nicht-standard-Orten zu suchen. Aber jeder nach seiner Fasson :) MfG Diez _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
On 27.06.06 17:05:15, Diez B. Roggisch wrote:
Das hatte ich schon, was aber fehlte war die Nennung des Packages "ui" in der Liste der packages...
Was für eine Nennung?
package_data = { # If any package contains files, include them '': ['*.ui'], }
inkludiert alle *ui-files aus welchem Package auch immer.
Ja, ich hate 'ui': ... und 'ui' nicht unter packages... Egal...
Hmm, aber irgendwie ist das nicht das was ich wollte, die ui-Dateien sollten in eigentlich nicht ins egg, sondern nach PYTHONHOME/share/<appname>. Sonst muss ich ja bei der Paketierung fuer Debian wieder "Verrenkungen" anstellen. Ausserdem hab ich auch noch Uebersetungsdateien die passend installiert werden muessen (die duerfen nicht ins egg)...
Ich arbeite unter Debian - und ich habe keine Verrenkungen. Wenn man mittels des im ersten meiner Postings beschriebenen resource managers auf die Dateien zugreift, ist alles was man angibt das Package & der Filename. Wenn das in einem Egg ist, dann wird es daraus sogar extrahiert (da egg ja gezippt und direkter File-access so nicht geht)-
Naja, das Problem dabei ist: Die Funktion die aus dem .ui dann eine Python-Klasse "erzeugt" erwartet einen Dateinamen und kommt mit dem zurueckgelieferten "Inhalt" der Datei so nicht zurecht. Gut da kann ich resource_filename fuer benutzen. Aber das folgende Problem ist wesentlich komplizierter fuer mich zu loesen... Also in xpathevaluator/xpathwidget.py steht: resource_string(__name__, 'ui/xpathwidget.ui') Was in einem Pfad resultiert der xpathevaluator/ui/xpathwidget.ui ist. Somit wirds nicht gefunden, weil die setuptools die ui-Dateien direkt unter ui/ legen (ohne das xpathevaluator davor). Ich braeuchte sowas wie resource_*(<nuescht>, 'ui/xpathwidget.ui')...
und im Sinne einer sauberen Installation sind eggs sicherlich vorzuziehen. Denn die kann man als Ganzes löschen, statt mühselig nach rumfliegenden Müll in nicht-standard-Orten zu suchen.
Ich hab mich zugegebenermassen noch nicht damit befasst wie Debian-Pakete von Python Applikationen aussehen, aber dort werden ja wohl keine eggs installiert (AFAIK). Mal schauen, eines nach dem anderen und jetzt erstmal die eggs. Das Problem mit den Uebersetzungen laesst sich auch loesen, aber irgendwie fuehlt sich das falsch an wenn ich extra Code schreiben muss damit die Uebersetzungen gefunden werden... Andreas -- Think twice before speaking, but don't say "think think click click". _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Naja, das Problem dabei ist: Die Funktion die aus dem .ui dann eine Python-Klasse "erzeugt" erwartet einen Dateinamen und kommt mit dem zurueckgelieferten "Inhalt" der Datei so nicht zurecht. Gut da kann ich resource_filename fuer benutzen.
Ich habe eh noch nie verstanden warum man ui-files unbedingt zur Laufzeit zu Widgets machen will. Klar das ich nicht an den generierten sourcen fummele - aber ich habe die immer übersetzt gespeichert. Na, Geschmackssache.
Aber das folgende Problem ist wesentlich komplizierter fuer mich zu loesen...
Also in xpathevaluator/xpathwidget.py steht: resource_string(__name__, 'ui/xpathwidget.ui')
Was in einem Pfad resultiert der
xpathevaluator/ui/xpathwidget.ui
ist. Somit wirds nicht gefunden, weil die setuptools die ui-Dateien direkt unter ui/ legen (ohne das xpathevaluator davor).
Ich braeuchte sowas wie resource_*(<nuescht>, 'ui/xpathwidget.ui')...
Hört sich für mich eher danach an, das du krampfhaft veruchst, eine bestehende Struktur in setuptools reinzuprügeln. Was ich für unsinnig halte. Pack die Dateien doch einfach nach xpathevaluator/ui. Wenn du dir zu viel Mühe gibst um die Art wie setuptools die Dinge handhabt rumzuarbeiten - dann lass es sein & strick es halt alles selbst. Aber "shoehorning" ist nie ne gute Idee. Und Tatsache ist, das man eine Applikation schon mit Hinblick auf deren roll-out planen muss. Klar, wenn man da zum Schluss rangeht, dann muss man halt nacharbeiten.
Ich hab mich zugegebenermassen noch nicht damit befasst wie Debian-Pakete von Python Applikationen aussehen, aber dort werden ja wohl keine eggs installiert (AFAIK). Mal schauen, eines nach dem anderen und jetzt erstmal die eggs.
Keine Ahung - Debian-Pakete sind ein komplett eigenes Ding. Debian separiert ja sogar python & python-dev. Was von vielen als unsinn empfunden wird. Eggs installiert man mittels easy_install. Aber grundsätzlich sind Debian-Pakete nix als Meta-Daten + ne Filehierarchie. Es sollte also auch möglich sein, deine Applikation als Deb-Paket zu erzeugen, welches die eggs enthält - ob das den Aufwand wert ist musst du selber entscheiden.
Das Problem mit den Uebersetzungen laesst sich auch loesen, aber irgendwie fuehlt sich das falsch an wenn ich extra Code schreiben muss damit die Uebersetzungen gefunden werden...
Keine Ahnung - ich erinnere mich nicht das du was zu Übertsetzungen geschrieben hast. Kann aber an mir liegen. Wenn du damit die üblich Qt-i18n meinst - auch da gilt natürlich dasselbe wie oben: wenn du es gleich im Hinblick auf setuptools machst, gehts gut. Wenn nicht - machstes halt selbst. Diez _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
On 27.06.06 18:27:24, Diez B. Roggisch wrote:
Naja, das Problem dabei ist: Die Funktion die aus dem .ui dann eine Python-Klasse "erzeugt" erwartet einen Dateinamen und kommt mit dem zurueckgelieferten "Inhalt" der Datei so nicht zurecht. Gut da kann ich resource_filename fuer benutzen.
Ich habe eh noch nie verstanden warum man ui-files unbedingt zur Laufzeit zu Widgets machen will. Klar das ich nicht an den generierten sourcen fummele - aber ich habe die immer übersetzt gespeichert. Na, Geschmackssache.
Weil das einfacher ist. Ansonsten muesste ich naemlich auch noch Code schreiben der die ui-Files mittels pyuic4 in Python Code umschreibt.
Aber das folgende Problem ist wesentlich komplizierter fuer mich zu loesen...
Also in xpathevaluator/xpathwidget.py steht: resource_string(__name__, 'ui/xpathwidget.ui')
Was in einem Pfad resultiert der
xpathevaluator/ui/xpathwidget.ui
ist. Somit wirds nicht gefunden, weil die setuptools die ui-Dateien direkt unter ui/ legen (ohne das xpathevaluator davor).
Ich braeuchte sowas wie resource_*(<nuescht>, 'ui/xpathwidget.ui')...
Hört sich für mich eher danach an, das du krampfhaft veruchst, eine bestehende Struktur in setuptools reinzuprügeln. Was ich für unsinnig halte. Pack die Dateien doch einfach nach xpathevaluator/ui.
Ja, das funktioniert. Nur missfaellt mir halt das die UI-Files im xpathevaluator-Modul liegen (bzw. darunter). Und was mache ich mit den Uebersetzungen... Die muessen dann ja auch nach xpathevaluator/qm oder sowas...
Wenn du dir zu viel Mühe gibst um die Art wie setuptools die Dinge handhabt rumzuarbeiten - dann lass es sein & strick es halt alles selbst. Aber "shoehorning" ist nie ne gute Idee.
Ist schon klar, deswegen versuche ich ja grade herauszufinden wie setuptools die Dinge handhabt, wie ich damit das hinkriege was ich moechte. Selbst schreiben kommt nicht in Frage, der Aufwand ist zu gross.
Und Tatsache ist, das man eine Applikation schon mit Hinblick auf deren roll-out planen muss. Klar, wenn man da zum Schluss rangeht, dann muss man halt nacharbeiten.
Das "umherschieben" der Ui-Dateien ist kein grosses Problem...
Eggs installiert man mittels easy_install.
Aber grundsätzlich sind Debian-Pakete nix als Meta-Daten + ne Filehierarchie. Es sollte also auch möglich sein, deine Applikation als Deb-Paket zu erzeugen, welches die eggs enthält - ob das den Aufwand wert ist musst du selber entscheiden.
Mein Ziel ist im Moment das beides gleich einfach ist, sowohl die Installation mit easy_install+setuptools als auch aus dem Code ein Debian-Paket zu bauen. Letzteres muss ja nun schon den Code aendern wg. dem Laden der Ui-Dateien (vllt. sollte ich doch lieber Python-Code vorher generieren lassen)
Das Problem mit den Uebersetzungen laesst sich auch loesen, aber irgendwie fuehlt sich das falsch an wenn ich extra Code schreiben muss damit die Uebersetzungen gefunden werden...
Keine Ahnung - ich erinnere mich nicht das du was zu Übertsetzungen geschrieben hast. Kann aber an mir liegen.
Nicht direkt, nein.
Wenn du damit die üblich Qt-i18n meinst - auch da gilt natürlich dasselbe wie oben: wenn du es gleich im Hinblick auf setuptools machst, gehts gut. Wenn nicht - machstes halt selbst.
Die Uebersetzungen koennte ich vmtl. sogar direkt aus dem string von ressource_string laden. Was mir ein wenig fehlt ist so ein paar real-World-Beispiele. Ich hatte im Cheeseshop schon geschaut und einiges runtergeladen, aber entweder war es zu "einfach" oder zu komplex.. Muss mal schauen ob ich davon noch welche als Debian-Quellpaket finde... Jedenfalls danke schonmal fuer die Anregungen und Hilfe. Andreas -- While you recently had your problems on the run, they've regrouped and are making another attack. _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
Hi Andreas, Andreas Pakulat schrieb:
On 27.06.06 18:27:24, Diez B. Roggisch wrote:
Hört sich für mich eher danach an, das du krampfhaft veruchst, eine bestehende Struktur in setuptools reinzuprügeln. Was ich für unsinnig halte. Pack die Dateien doch einfach nach xpathevaluator/ui.
Ja, das funktioniert. Nur missfaellt mir halt das die UI-Files im xpathevaluator-Modul liegen (bzw. darunter).
Und was mache ich mit den Uebersetzungen... Die muessen dann ja auch nach xpathevaluator/qm oder sowas...
Eben da, wo sie hingehören. Sind doch Teil deines Programms, oder? Die werden doch bestimmt nicht in mehreren Paketen gebraucht... In Slow lasse ich übrigens auch den Source erzeugen und legen den dann ins Ei mit rein. Finde ich einfacher als mich zur Laufzeit mit .ui Dateien herumzuschlagen.
Wenn du dir zu viel Mühe gibst um die Art wie setuptools die Dinge handhabt rumzuarbeiten - dann lass es sein & strick es halt alles selbst. Aber "shoehorning" ist nie ne gute Idee.
Ist schon klar, deswegen versuche ich ja grade herauszufinden wie setuptools die Dinge handhabt, wie ich damit das hinkriege was ich moechte. Selbst schreiben kommt nicht in Frage, der Aufwand ist zu gross.
Vielleicht solltest du einfach mal in die Dokumentation reinschauen. Die distutils sind eigentlich ganz verständlich beschrieben (und von den setuptools benutzt du ja ohnehin kaum etwas). Stefan _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
On 27.06.06 19:39:09, Stefan Behnel wrote:
Andreas Pakulat schrieb:
On 27.06.06 18:27:24, Diez B. Roggisch wrote:
Hört sich für mich eher danach an, das du krampfhaft veruchst, eine bestehende Struktur in setuptools reinzuprügeln. Was ich für unsinnig halte. Pack die Dateien doch einfach nach xpathevaluator/ui.
Ja, das funktioniert. Nur missfaellt mir halt das die UI-Files im xpathevaluator-Modul liegen (bzw. darunter).
Und was mache ich mit den Uebersetzungen... Die muessen dann ja auch nach xpathevaluator/qm oder sowas...
Eben da, wo sie hingehören. Sind doch Teil deines Programms, oder? Die werden doch bestimmt nicht in mehreren Paketen gebraucht...
In Slow lasse ich übrigens auch den Source erzeugen und legen den dann ins Ei mit rein. Finde ich einfacher als mich zur Laufzeit mit .ui Dateien herumzuschlagen.
Ha, endlich mal ein wirklich gutes Beispiel :-) Ich werd mal ein wenig bei slow stibitzen wenn du nichts dagegen hast...
Wenn du dir zu viel Mühe gibst um die Art wie setuptools die Dinge handhabt rumzuarbeiten - dann lass es sein & strick es halt alles selbst. Aber "shoehorning" ist nie ne gute Idee.
Ist schon klar, deswegen versuche ich ja grade herauszufinden wie setuptools die Dinge handhabt, wie ich damit das hinkriege was ich moechte. Selbst schreiben kommt nicht in Frage, der Aufwand ist zu gross.
Vielleicht solltest du einfach mal in die Dokumentation reinschauen. Die distutils sind eigentlich ganz verständlich beschrieben (und von den setuptools benutzt du ja ohnehin kaum etwas).
Ich war der Meinung ich haette distutils gelesen aber ich hatte sowieso vor das nochmal zu tun, "spaeter" ;-) Andreas -- You have an ability to sense and know higher truth. _______________________________________________ python-de maillist - python-de@python.net http://python.net/mailman/listinfo/python-de
participants (3)
-
Andreas Pakulat -
Diez B. Roggisch -
Stefan Behnel