Was ist die beste Projektstruktur für eine Python-Anwendung?

Question

Stellen Sie sich vor, Sie möchten eine nicht-triviale Desktop-Anwendung (nicht Web-Anwendung) in Python für Endbenutzer entwickeln. Wie lässt sich die Ordnerhierarchie des Projekts am besten strukturieren?

Wünschenswerte Eigenschaften sind einfache Wartung, IDE-Freundlichkeit, Eignung für Source Control Branching/Merging und einfache Erzeugung von Installationspaketen.

Im Besonderen:

1. Wo wird die Quelle angegeben?
2. Wo werden Skripte zum Starten von Anwendungen abgelegt?
3. Wohin kommt der IDE-Projektschrott?
4. Wo platzieren Sie die Unit/Akzeptanztests?
5. Wo legen Sie Nicht-Python-Daten wie Konfigurationsdateien ab?
6. Wo legt man Nicht-Python-Quellen wie C++ für die binären Erweiterungsmodule von pyd/so ab?

Answer 1

Das spielt keine allzu große Rolle. Was auch immer Sie glücklich macht, wird funktionieren. Es gibt nicht viele dumme Regeln, weil Python-Projekte einfach sein können.

• /scripts o /bin für diese Art von Befehlszeilenschnittstelle
• /tests für Ihre Tests
• /lib für Ihre C-Sprachbibliotheken
• /doc für die meisten Dokumentationen
• /apidoc für die von Epydoc erstellten API-Dokumente.

Und das oberste Verzeichnis kann README's, Config's und ähnliches enthalten.

Die schwierige Entscheidung ist, ob man eine /src Baum. In Python gibt es keine Unterscheidung zwischen /src , /lib et /bin wie Java oder C hat.

Da eine Top-Level /src Verzeichnis von einigen als bedeutungslos angesehen wird, kann Ihr Top-Level-Verzeichnis die Top-Level-Architektur Ihrer Anwendung sein.

• /foo
• /bar
• /baz

Ich empfehle, dies alles in das Verzeichnis "Name meines Produkts" zu legen. Wenn Sie also eine Anwendung schreiben, die quux Das Verzeichnis, das all diese Daten enthält, heißt /quux .

Das Projekt eines anderen PYTHONPATH kann also umfassen /path/to/quux/foo zur Wiederverwendung der QUUX.foo Modul.

In meinem Fall, da ich Komodo Edit verwende, ist mein IDE-Cuft eine einzige .KPF-Datei. Ich lege sie in der obersten Ebene /quux Verzeichnis und fügen Sie es nicht zu SVN hinzu.

Answer 2

Nach dem Buch von Jean-Paul Calderone Dateisystemstruktur eines Python-Projekts :

Project/
|-- bin/
|   |-- project
|
|-- project/
|   |-- test/
|   |   |-- __init__.py
|   |   |-- test_main.py
|   |   
|   |-- __init__.py
|   |-- main.py
|
|-- setup.py
|-- README

Answer 3

Este Blog-Beitrag von Jean-Paul Calderone wird üblicherweise als Antwort in #python auf Freenode gegeben.

Dateisystemstruktur eines Python-Projekts

Machen:

• Benennen Sie das Verzeichnis mit einem Namen, der sich auf Ihr Projekt bezieht. Wenn Ihr Projekt zum Beispiel "Twisted" heißt, nennen Sie das oberste Verzeichnis für die Quelldateien Twisted . Bei der Freigabe sollten Sie eine Versionsnummer als Suffix angeben: Twisted-2.5 .
• ein Verzeichnis erstellen Twisted/bin und legen Sie dort Ihre ausführbaren Dateien ab, falls Sie welche haben. Geben Sie ihnen keinen .py Erweiterung, auch wenn es sich um Python-Quelldateien handelt. Fügen Sie keinen Code in sie ein, außer einem Import von und einem Aufruf einer Hauptfunktion, die irgendwo anders in Ihren Projekten definiert ist. (Kleines Problem: Da unter Windows der Interpreter durch die Dateierweiterung ausgewählt wird, wollen Ihre Windows-Benutzer die .py-Erweiterung tatsächlich haben. Wenn Sie also für Windows paketieren, sollten Sie sie hinzufügen. Leider gibt es keinen mir bekannten einfachen Distutils-Trick, um diesen Prozess zu automatisieren. Wenn man bedenkt, dass unter POSIX die .py-Erweiterung nur eine Warze ist, während unter Windows das Fehlen ein echter Fehler ist, sollten Sie, wenn Sie Windows-Benutzer haben, die .py-Erweiterung einfach überall haben).
• Wenn Ihr Projekt in einer einzigen Python-Quelldatei ausgedrückt werden kann, legen Sie diese in das Verzeichnis und geben Sie ihr einen Namen, der sich auf Ihr Projekt bezieht. Zum Beispiel, Twisted/twisted.py . Wenn Sie mehrere Quelldateien benötigen, erstellen Sie stattdessen ein Paket ( Twisted/twisted/ mit einer leeren Twisted/twisted/__init__.py ) und legen Sie Ihre Quelldateien darin ab. Zum Beispiel, Twisted/twisted/internet.py .
• Legen Sie Ihre Unit-Tests in einem Unterpaket Ihres Pakets ab (Achtung - das bedeutet, dass die obige Option einer einzelnen Python-Quelldatei ein Trick war - Sie immer benötigen Sie mindestens eine weitere Datei für Ihre Unit-Tests). Zum Beispiel, Twisted/twisted/test/ . Natürlich, machen Sie daraus ein Paket mit Twisted/twisted/test/__init__.py . Platzieren Sie Tests in Dateien wie Twisted/twisted/test/test_internet.py .
• hinzufügen. Twisted/README y Twisted/setup.py um Ihre Software zu erklären bzw. zu installieren, wenn Sie so nett sind.

Tun Sie es nicht:

• legen Sie Ihren Quelltext in ein Verzeichnis namens src o lib . Dies macht es schwierig, ohne Installation zu arbeiten.
• legen Sie Ihre Tests außerhalb Ihres Python-Pakets ab. Das macht es schwierig, die Tests gegen eine installierte Version laufen zu lassen.
• ein Paket erstellen, das nur hat eine __init__.py und fügen Sie dann Ihren gesamten Code in __init__.py . Machen Sie einfach ein Modul anstelle eines Pakets, das ist einfacher.
• versuchen, magische Hacks zu erfinden, um Python in die Lage zu versetzen, Ihr Modul oder Paket zu importieren, ohne dass der Benutzer das Verzeichnis, das es enthält, zu seinem Importpfad hinzufügen muss (entweder über PYTHONPATH oder einen anderen Mechanismus). Sie werden no richtig mit allen Fällen umgehen, und die Benutzer werden wütend auf Sie sein, wenn Ihre Software in ihrer Umgebung nicht funktioniert.

Answer 4

Vérifiez Open Sourcing eines Python-Projekts auf die richtige Art .

Lassen Sie mich einen Auszug aus dem Projektgestaltung Teil dieses ausgezeichneten Artikels:

Beim Einrichten eines Projekts ist es wichtig, dass das Layout (oder die Verzeichnisstruktur) stimmt. Ein vernünftiges Layout bedeutet, dass potenzielle Mitwirkende nicht ewig nach einem Stück Code suchen müssen; die Dateispeicherorte sind intuitiv. Da wir es mit einem bestehenden Projekt zu tun haben, müssen Sie wahrscheinlich einige Dinge umstellen.

Beginnen wir an der Spitze. Die meisten Projekte haben eine Reihe von Dateien auf oberster Ebene (wie setup.py, README.md, requirements.txt, usw.). Dann gibt es drei Verzeichnisse, die jedes Projekt haben sollte:

• Ein docs-Verzeichnis mit der Projektdokumentation
• Ein Verzeichnis mit dem Namen des Projekts, in dem das aktuelle Python-Paket gespeichert ist

• Ein Testverzeichnis an einem von zwei Orten

  • Unter dem Paketverzeichnis, das den Testcode und die Ressourcen enthält
  • Als eigenständiges Verzeichnis der obersten Ebene Um ein besseres Gefühl dafür zu bekommen, wie Ihre Dateien organisiert sein sollten, hier ein vereinfachter Schnappschuss des Layouts für eines meiner Projekte, sandman:

  $ pwd ~/code/sandman $ tree . |- LICENSE |- README.md |- TODO.md |- docs | |-- conf.py | |-- generated | |-- index.rst | |-- installation.rst | |-- modules.rst | |-- quickstart.rst | |-- sandman.rst |- requirements.txt |- sandman | |-- init.py | |-- exception.py | |-- model.py | |-- sandman.py | |-- test | |-- models.py | |-- test_sandman.py |- setup.py

Wie Sie sehen können, gibt es einige Dateien auf oberster Ebene, ein docs-Verzeichnis (generiert ist ein leeres Verzeichnis, in dem sphinx die generierte Dokumentation ablegt), ein sandman-Verzeichnis und ein Testverzeichnis unter sandman.

Answer 5

Die "Python Packaging Authority" hat ein Beispielprojekt:

https://github.com/pypa/sampleproject

Es handelt sich um ein Beispielprojekt, das als Hilfsmittel für das Tutorial über das Verpacken und Verteilen von Projekten im Python Packaging User Guide dient.