Frage Was ist eine gute Ordnerstruktur für die Multiplattform-Verteilung einer Python-Anwendung? [geschlossen]


Tut mir leid wegen der Textwand, aber ich versuche, meine Frage gut zu verstehen. Eigentlich gibt es hier eine Million Fragen, weil ich völlig verwirrt bin. Ich habe vor kurzem einige Python-Programmierung gelernt und eine Windows-Anwendung gemacht. Jetzt möchte ich diese App und ein paar andere Ideen für Ubuntu implementieren und als Open Source GPL-3 veröffentlichen. Obwohl ich möchte, dass der Code auf jedem System (oder zumindest Ubuntu und Windows) laufen kann.

Um zu erfahren, wie Ubuntu-Pakete funktionieren, habe ich mir die kürzlich im App Developer Showdown verwendete Anwendung angeschaut. Aber die Ordnerstruktur und die daraus entstehenden Dateien ergeben für mich überhaupt keinen Sinn. Also lese ich die Ubuntu-Verpackungshandbuch und das Anwendungsüberprüfungsprozess mit allen Links dort, sowie der Debian Python-Richtlinie. Aber dieser ganze Text hat nur dazu geführt, mich verwirrter über die Art zu machen, wie Dateien und Ordner schnell erstellt werden.

Der schnelle Weg?

Also, das verstehe ich schnell (vorausgesetzt, mein Projektname ist proj):

proj/bin = eine einzelne Datei, die nach /usr/share/bin/proj.py kopiert wird, um die App von einem globalen Pfad aus zu starten? Aber das wäre ein Verstoß gegen die Regeln des "Application Review Process", oder?
proj/data/* = Dateien, die unter / usr / share / proj / * liegen sollten, oder? Aber das wäre auch ein Verstoß gegen die Regeln des "Application Review Process"?
proj/help/C/* = Ich denke, einige HTML-Dokumentation sollte unter / usr / share / doc / proj / gehen und das funktioniert gut mit "Application Review Process", aber warum ist der Ordnername "C" und nicht nur "proj"?
proj/tests/ = irgendeine Art von Dateien für ein "Test" -Paket in Python. Ich denke, das ist großartig, ich freue mich darauf zu erfahren, was es ist.
proj/proj/ = einige Dateien, die scheinbar mit neuen Dateien im Ordner proj_lib verknüpft sind? Scheint unnötig, und ich verstehe nicht, warum diese überhaupt hier sind.
proj/proj_lib/ = der eigentliche Quellcode, denke ich?

Dann schnell auch erstellt proj/apport und proj/etc/apport* was ich nicht weiß, was sie tun oder warum sie hinzugefügt werden.

Nun, der wirklich verwirrende Teil ist die Dateistruktur. Es sieht so aus als hätte ich noch nichts gesehen. Und um ehrlich zu sein, sieht es so aus sehr kompliziert in unnötiger Weise. Unter diesem Abschnitt werde ich beschreiben, wie ich meine eigene Projektdateistruktur erstellen würde, die helfen könnte zu beschreiben, warum dies für mich so verwirrend ist. Aber zuerst, mein Verständnis des schnellen Weges (beachte, dass mein Verständnis zu diesem Zeitpunkt falsch ist).

Zuallererst, die setup.py. Diese Datei enthält eine Funktion namens update_config (), die einfach eine andere Datei namens proj / proj_lib / projconfig.py lädt. Aber diese config.py-Datei scheint nichts zu enthalten, was nützlich wäre, um von setup.py getrennt zu bleiben. Tatsächlich gibt es eine Menge Dinge, von denen ich noch nie jemanden in einer setup.py-Datei vorgeschlagen habe. Die Datei setup.py enthält außerdem einen fest codierten Dateinamen, der auf das SVG-Symbol verweist, und kopiert ansonsten einfach die Datei desktop.in auf sich selbst. Warum also nicht einfach die Änderungen direkt in der desktop.in-Datei ohne diese Funktion im Setup vornehmen .py? Dann gibt es eine andere Funktion, um ein Unterverzeichnis proj / data / share / proj zu erstellen und die desktop.in-Datei dort zu kopieren, was ich nicht verstehe, den Zweck? Warum haben Sie eine Funktion, die das macht, wenn Sie die Datei ursprünglich dort haben können? Dann Nach all dem unsinnigen Code kommt etwas, das tatsächlich wie ein reguläres setup.py aussieht.

Jetzt die proj/bin/proj.py, von dem ich vermute, dass es verwendet werden soll, um die Anwendung zu starten? Dies scheint gerade / usr / to /opt/extras.ubuntu.com/ in einer zuvor nicht deklarierten syspath-Variablen neu zu ordnen. Also denke ich, dass dies den Regeln im "Application Review Process" für Apps gerecht wird, die den Ordnernamen für alle anderen Linux-Varianten verwenden? Fair genug, ich verstehe es nicht, aber ich kann damit leben. Nach dieser Neuabbildung der Verzeichnisse fährt diese Datei fort, proj / proj /drin.py.

proj/proj/__init__.py ist der Standardweg, um zu definieren, wie man ein Modul startet, denke ich? Aber anstatt etwas Code zu haben, der tatsächlich etwas bewirkt, läuft diese Datei weiter, um wiederum die Hauptfensterklasse auszuführen, die sich in einer anderen Datei befindet.

proj/proj_lib/ hat auch ein drin.py-Datei, die ich nicht verstehe, den Zweck von. Dann gibt es ein Window.py, das scheinbar die eigentliche Funktionalität der Anwendung enthält und andere Fensterpy-Dateien wie etwa Dialog usw. aufruft.

So wie ich meine App gemacht habe

Meine Ordnerstruktur sieht folgendermaßen aus:

proj/
proj/ui
proj/imageformats # necessary for imports to work
proj/sqldrivers   # necessary for imports to work

In dem proj/ Ordner Ich habe meine setup.py und meine proj.py, die meine App startet. In meiner Datei proj.py habe ich alle Funktionen des Hauptfensters, einige andere Fenster und Funktionen mit Importen aufrufen, und am Ende dieser Datei ist die Main() Funktion, die die App startet.

Das proj/ui/ Ordner enthält alle meine .ui-Dateien, die mit Qt Designer erstellt wurden.

Die anderen Ordner dienen nur dazu, einige Dateien bereitzustellen, die die Anwendung funktionieren lassen, wenn sie mit py2exe für Windows gepackt werden. Im Grunde sind das die Dateien, die durch Abhängigkeiten in Ubuntu bereitgestellt werden.

Beachten Sie, dass dieses Setup sehr gut für die Windows-Entwicklung funktioniert. Ich benutze py2exe, um eine ausführbare Datei zu erstellen, die in einem endet proj/dist/ Ordner, und ich kann nur die Dateien in diesem Ordner kopieren und es wird auf jedem Windows-Rechner funktionieren.

Wie kombiniere ich das?

Ich habe ein paar Tage damit verbracht, Dokumentation zu lesen. Es gibt kaum etwas, auf dem ich schnell finden kann, außer dem grundlegenden Tutorial und den Sachen auf App Developer Showdown Workshops. Ich kann dort nichts finden, was mir hilft, die von mir vorgeschlagene Ordnerstruktur schnell zu verstehen.

Nach dem, was ich gelesen habe, könnte ich verwenden os.environ['HOME'] um einen Pfad zu ~ / .config / proj.conf unter Ubuntu oder C: /Users/username/.config/proj.conf unter Windows zu erstellen. So weit kann ich den plattformübergreifenden Code beibehalten. Aber dann mit der Aufteilung in / bin und / etc und / opt werde ich anfangen, auf einige Probleme zu stoßen. Natürlich könnte ich als letzten Ausweg zwei Kopien des Codes behalten - einen für Ubuntu und einen für Windows. Aber ich möchte trotzdem eine ähnliche Ordnerstruktur, um die Übertragung von Codeänderungen zu vereinfachen.

Da sollte jemand sein, der dafür schon eine gute Lösung hat. Und vielleicht könnte diese Person auch (neben einem Beispiel dafür, wie man es plattformübergreifend macht) beschreiben, warum es so eine lange Kette von Dateien gibt, die andere Dateien aufrufen, die andere Dateien in der Standard-Schnelleinrichtung aufrufen? Natürlich gehe ich jetzt davon aus, dass schnell eine Art empfohlenes Modell für Ubuntu verwendet wird. Wenn das nicht der Fall ist, würde ich gerne Vorschläge bekommen, was eine empfohlene Ordnerstruktur wäre, um eine Anwendung über Ubuntu-Repositories zu verteilen?


4
2017-07-10 23:12


Ursprung


Finden Sie eine beliebte Anwendung, extrahieren Sie sie und sehen Sie, wie sie es gemacht hat. - Sepero
Außerdem ist dies keine Ubuntu-spezifische Frage - es würde besser zum stackoverflow IMHO passen (auch bessere Chancen für gute Antworten). Sie können es dort AFAIK bewegen lassen, wenn es entsprechend gekennzeichnet wird. - Izzy
AFAIK, ist schnell eine Ubuntu-spezifische Anwendung, und ich versuche das zu verwenden, um "zu sehen, wie sie es machen", wie Sepero vorgeschlagen hat. Die Regel zum Angeben von Anwendungen in / opt anstelle von / usr ist Ubuntu-spezifisch. Dies ist keine allgemeine Frage in diesem Sinne, da es sich um Besonderheiten handelt, wie Python auf Ubuntu zu verteilen ist (aber es weiterhin für andere Betriebssysteme offen hält). - GaRyu
Während es sich um ein Thema für Ask Ubuntu handelt, sieht es für mich wie eine Diskussion aus, die auf der Schnellliste zu finden ist launchpad.net/~quickly-talkeher als eine Frage. - David Planella
Ich habe die von mir zur Verfügung gestellte Struktur schnell als Beispiel benutzt, weil ich davon ausgehe, dass sie durchdacht ist. Wie durchdacht es auch ist, es gibt keine Dokumentation, die die Gedanken dahinter erklärt. Natürlich könnte dies auf der Quickly-Liste diskutiert werden, wie Sie sagen. Aber dann geht es nicht nur darum, wie schnell es geht. Die Frage ist, wie richte ich die Dinge so ein, dass sie den Ubuntu-Spezifikationen (wie schnell) entsprechen, während es gleichzeitig einfach ist, auf Windows oder anderen Plattformen zu laufen? Dies ist in keiner Weise schnell-spezifisch, es verwendet nur schnell als Ausgangspunkt für die Diskussion. - GaRyu


Antworten:


Nach vielem Googeln außerhalb von Ubuntu-spezifischen oder Debian-spezifischen Seiten fand ich dieses das war eigentlich ziemlich hilfreich. Grundsätzlich ist der Vorschlag, es so zu halten:

proj/
proj/bin/proj.py                 # this will just "import proj" and "main()"
proj/proj/__init__.py            # this will just "import window.py" and run that
proj/proj/window.py              # main functionality
proj/proj/submodule/__init__.py  # import in window.py
proj/proj/test/                  # for that test package that quickly also uses
proj/README                      # basic readme file
proj/setup.py                    # standard distutils setup.py

Das klingt für mich vernünftiger als der schnelle Weg und näher an meinem ursprünglichen Weg. Und es sollte nicht unmöglich sein, es zu einem Debian-Paket zu machen, das den Ubuntu-Richtlinien folgt? Also ich denke, ich werde einfach die schnellen Sachen löschen und das tun. Es sei denn, jemand hat einen besseren Vorschlag?

Was bleibt dann hier ist, "wie installiere ich das gut auf Ubuntu, sowie Windows?", D. H. Sollte ich setup.py in einer speziellen Weise codieren oder andere Überlegungen im Code machen ...


4
2017-07-11 10:17