Setuptools für locales und zusätzliche Daten

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
Antworten
Benutzeravatar
tiax
User
Beiträge: 152
Registriert: Samstag 23. Juli 2005, 17:28
Kontaktdaten:

Montag 7. Juli 2008, 01:39

Hi,

nachdem ich bisher immer "zweckgebunden" programmiert habe und mich nicht besonders um Weiterverteilung von Paketen habe kümmern müssen, ändert sich das nun endlich - ein OpenSource-Projekt!

Nebst Quellcode gibt es da noch eine gewisse Anzahl anderer Dateien. Zum einen wären das die locales, halt die ganzen .mo-Dateien, zum anderen wären das noch themes für die Oberfläche (ini-Dateien mit Farbdefinitionen). Die wollen, nebst Quellcode, versteht sich, ebenfalls installiert sein.

Ich habe nun angefangen, das mit setuptools zu machen. Solange locales und themes im Quellcode-Verzeichnis bleiben (so wie bisher auch gegeben beim Programm), klappt alles ganz gut. Nachdem allerdings auch ein Debian-Paket erstellt werden soll, dachte ich, wäre es notwendig, dass die locales nach /usr/share/locales/ und die themes nach /usr/share/pyroom/themes kämen, um sich an gewisse Standards zu halten.

Jetzt hab ich einige Dinge über die setuptools gelesen, konnte dabei jetzt aber nicht so recht verstehen, ob das überhaupt möglich (und gewollt) ist und wenn ja, wie.

Inwiefern muss ich denn da die Angaben für die setuptools anpassen?
Ne invoces expellere non possis
[url=xmpp://florian@florianheinle.de]xmpp:florian@florianheinle.de[/url]
lunar

Montag 7. Juli 2008, 13:19

Bleib bei setuptools, der Installation als "package data" und "pkg_resources". Das ist zwar inkompatibel zum FHS, aber es ist eigentlich nicht meine Aufgabe als Entwickler, mich darum zu kümmern. Das ist die Aufgabe des Distributionstools, in diesem Fall also der distutils/setuptools, genauso wie cmake oder autotools das bei C oder C++-Anwendungen übernehmen.

Außerdem bietet das eine Reihe weiterer Vorteile: Es ist schnell und bequem für den Entwickler, die Anwendung wird "easy_install"able und man kann Eggs bauen, was die Distribution ungemein erleichtert. Und den meisten Nutzern dürfte es ziemlich egal sein ...

Imho ist es mehr wert, ein standardisiertes Installationstool zu nutzen als den FHS auf Teufel einhalten zu wollen. Ich habe das auch mal versucht, und fand es ziemlich ätzend, weil man sich dauernd mit irgendwelchen Installationspräfixen rumschlagen muss.

Summa summarum: Fuck of FHS, ein Hoch auf die setuptools ;)

Btw, für die locales empfiehlt sich die Nutzung von "babel". Damit wird die Anwendung unabhängig von xgettext und Konsorten und kann auch unter Windows ohne Probleme gebaut werden.
Benutzeravatar
tiax
User
Beiträge: 152
Registriert: Samstag 23. Juli 2005, 17:28
Kontaktdaten:

Montag 7. Juli 2008, 14:43

Ja, diese Art und Weise gefällt mir auch wesentlich besser.

Beim Antrag auf Aufnahme in Ubuntu allerdings wurde angemerkt, dass man doch die locales nach /usr/share/locales installieren solle.

Wie ist dann hier best practice? Für das Debian-Paket manuell alles nochmal umwerfen und es da "von Hand" hin installieren lassen?

Dazu gleich dann die nächste Frage: Bisher habe ich PackagingGuides gelesen, die auch die setuptools verwendet haben. Die würden ja dann auch meine locales ins Verzeichnis unter site-packages installieren und wenn ich sie von hand an den richtigen Ort installieren lasse vom Debian-Paket, wären sie ja doppelt?

Wie ist denn da die "best practice"?
bzgl babel: danke, schau ich mir an
Ne invoces expellere non possis
[url=xmpp://florian@florianheinle.de]xmpp:florian@florianheinle.de[/url]
lunar

Montag 7. Juli 2008, 15:24

tiax hat geschrieben:Beim Antrag auf Aufnahme in Ubuntu allerdings wurde angemerkt, dass man doch die locales nach /usr/share/locales installieren solle.
Dann frag mal vorsichtig nach, wie die sich das vorstellen und weise bei der Gelegenheit auch drauf hin, dass das bei Django offenbar nicht so ernst gesehen wurde. Dessen locales liegen nämlich auch nicht unter "/usr/share/locales".

Imho hat da jemand ohne Ahnung von der Situation, aber mit viel Halbwissen über den FHS was Tolles in den Raum geworfen.
Wie ist dann hier best practice? Für das Debian-Paket manuell alles nochmal umwerfen und es da "von Hand" hin installieren lassen?
Im Zweifelsfall würde ich beim Bauen des Pakets die Locales manuell verschieben und dann die Gettext-Logik im Programm über einen Patch verändern.

Ich würde aber davon absehen, dass auf das ganze Programm auszudehnen. Dann muss man nämlich mit Sonderfällen und Präfixen kämpfen, während man bei einem Ubuntu/Debian Paket eine klar definierte Umgebung hat (und beispielsweise den Pfad zu den Locales nicht zur Laufzeit bestimmen muss, sondern hart kodieren kann).

Außerdem macht das die Installation eines Pakets für die Nutzer anderer Distributionen einfacher, da sie sich auf die Standards der setuptools verlassen können (und ein Programm beispielsweise über das Löschen des Eggs aus site-packages entfernen können, ohne zu fürchten, irgendwo was hinterlassen zu haben).
Benutzeravatar
tiax
User
Beiträge: 152
Registriert: Samstag 23. Juli 2005, 17:28
Kontaktdaten:

Montag 7. Juli 2008, 16:05

Ok überzeugt, so herum ist es ja auch wesentlich sinnvoller.

Nun steh ich gleich vor dem nächsten Problem, gleiches Oberthema aber noch. Jetzt hab ich das so machen wollen, wenn ich allerdings das egg erstellen lasse, kommen im locale/ Ordner da drin nur 3 Dateien vor, statt ein Unterverzeichnis pro Sprache (mit jeweils einer gleichnamigen Datei natürlich).

Die Dateistruktur ist

Code: Alles auswählen

locale/
 |-ru
 |-ro
 |-...
themes/
 |-green.theme
 |-...
PyRoom/
 |-*.py
dazu, dachte ich, mach ich mir eine setup.py, bei der jede Datei unterhalb locales/ automatisch hinzugefügt wird: http://dpaste.com/61138/

Was läuft hier schief?
Ne invoces expellere non possis
[url=xmpp://florian@florianheinle.de]xmpp:florian@florianheinle.de[/url]
Benutzeravatar
tiax
User
Beiträge: 152
Registriert: Samstag 23. Juli 2005, 17:28
Kontaktdaten:

Dienstag 8. Juli 2008, 18:01

Ne invoces expellere non possis
[url=xmpp://florian@florianheinle.de]xmpp:florian@florianheinle.de[/url]
Leonidas
Administrator
Beiträge: 16024
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Sonntag 13. Juli 2008, 20:56

lunar hat geschrieben:Außerdem macht das die Installation eines Pakets für die Nutzer anderer Distributionen einfacher, da sie sich auf die Standards der setuptools verlassen können (und ein Programm beispielsweise über das Löschen des Eggs aus site-packages entfernen können, ohne zu fürchten, irgendwo was hinterlassen zu haben).
Ganz so einfach ist das aber nicht, denn PJE hat nicht vorgesehen, dass User das Zeug gegebenfalls auch deinstallieren wollen. Zed Shaws easy_fucking_uninstall löscht beispielsweise auch keine Skripte die ins BINDIR kommen.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
lunar

Sonntag 13. Juli 2008, 23:46

Leonidas hat geschrieben:
lunar hat geschrieben:Außerdem macht das die Installation eines Pakets für die Nutzer anderer Distributionen einfacher, da sie sich auf die Standards der setuptools verlassen können (und ein Programm beispielsweise über das Löschen des Eggs aus site-packages entfernen können, ohne zu fürchten, irgendwo was hinterlassen zu haben).
Ganz so einfach ist das aber nicht, denn PJE hat nicht vorgesehen, dass User das Zeug gegebenfalls auch deinstallieren wollen.
Welches Buildsystem kann das schon? Ich kenne autotools, cmake, qmake, boost.jam, scons und CPAN, und keines davon bietet standardmäßig einen Funktion zum Deinstallieren. Dafür hat man ja eigentlich den Paketmanager.

Bei Standard-Paketen hat man wenigstens den Vorteil, dass außer Skripten nichts außerhalb von site-packages liegt. Das macht die Deinstallation wenigstens etwas einfacher. Bei einer selbst gebastelten Lösung sind die Dateien ja sonst über alle möglichen FHS-Verzeichnisse verstreut.

Btw, ich hab mich mal an einem Deinstallationsskript versucht, rausgekommen ist: http://paste.pocoo.org/show/79381/
Normale Egg-Installationen dürfte das anstandslos entfernen, und das mit ~ 180 Zeilen. So schwer scheint das dann auch nicht zu sein ...
Antworten