Sinnvolle Projektstruktur

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.
Benutzeravatar
keppla
User
Beiträge: 483
Registriert: Montag 31. Oktober 2005, 00:12

Sinnvolle Projektstruktur

Beitragvon keppla » Donnerstag 14. Dezember 2006, 20:06

Hallo Forum,

ich bastele gerade an einem Projekt, bestehend aus einer Server- und einer Clientkomponente, und bin mir sehr unschlüssig, wie man die Dateien, Packages, Setup-Dateien, nicht-Python-Daten, etc Sinnvoll organisiert.

Server und Client in einem SVN-Repository? Was wäre mit geteilten Dateien? Server und Client als Subpackages eines Hauptpackages oder beide 1st-Level-Packages*? Wohin mit den setup.py-scripten?

Gibt es da offizielle "best practices"? Wie macht ihr das bzw. würdet es machen?

*) einerseits "flat is better than nested", andererseits hässliche Namen wie "myapp_server" und "myapp_client"
BlackJack

Beitragvon BlackJack » Donnerstag 14. Dezember 2006, 20:37

Falls die beiden Teile nicht zu gross sind/werden, würde ich einfach Client und Server als eine Anwendung entwickeln.

Die Luxusvariante wären natürlich drei Projekte, je eins für Client, Server und ein Package mit den gemeinsamen Modulen. Auf drei Repositories verteilen wäre natürlich übertrieben. Die Verzeichnisaufteilung könnte man so gestalten:

project/
  client/
     trunk/
     tags/
     branches/
  server/
     trunk/
     tags/
     branches/
  common/
     trunk/
     tags/
     branches/

Wobei in `common` der gemeinsame Quelltext steht und den kann man dann entweder separat installieren oder mit dem `svn:external`-Property in die Verzeichnisse von `client` und `server` integrieren.
Benutzeravatar
Joghurt
User
Beiträge: 877
Registriert: Dienstag 15. Februar 2005, 15:07

Beitragvon Joghurt » Donnerstag 14. Dezember 2006, 21:41

Wäre es nicht so sinnvoller?

Code: Alles auswählen

project/
 trunk/
  client/
  server/
  common/
 tags/
  ..
 branches/
Sonst muss man client und server getrennt auschecken und auchnoch dafür Sorge tragen, dass man immer zueinander kompatible Versionen auscheckt/taggt/etc.
BlackJack

Beitragvon BlackJack » Donnerstag 14. Dezember 2006, 22:22

Das kommt darauf an wie eng Client und Server zusammenhängen. Wenn die wirklich von ganz verschiedenen Personen an verschiedenen Orten installiert werden, dann kann das schon Sinn machen.

Sagen wir mal es ist (noch) ein Chatserver. Man kann ja nicht verlangen, dass bei jedem Serverupdate alle Benutzer einen genau zu diesem Server passenden Client installieren, der weder mit der letzten noch mit der nächsten Serverversion funktioniert. Wenn man ein stabiles Protokoll hat, dann können beide auch unabhängig entwickelt werden.

Aber wie schon gesagt: Ich würde die simpelste Möglichkeit empfehlen. Soweit möglich/sinnvoll also alles in ein Projekt:

project/
  trunk/
    spam_client.py
    spam_server.py
    common/
  tags/
  branches/
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Beitragvon Leonidas » Donnerstag 14. Dezember 2006, 22:36

BlackJack hat geschrieben:project/
trunk/
spam_client.py
spam_server.py
common/
tags/
branches/

So mache ich es zum Beispiel - ich habe mein Repository auf mehrere Projekte eingeteilt und eines davon dient als eine Art Inkubator - wenn etwas größer wird, dann bekommt es einen eigenen Projektordner mit trunk, branches und tags.
Zuletzt geändert von Leonidas am Donnerstag 14. Dezember 2006, 23:39, insgesamt 1-mal geändert.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Benutzeravatar
keppla
User
Beiträge: 483
Registriert: Montag 31. Oktober 2005, 00:12

Beitragvon keppla » Donnerstag 14. Dezember 2006, 23:23

Erstmal danke für die Antworten.

Code: Alles auswählen

project/
  trunk/
    spam_client.py
    spam_server.py
    common/
  tags/
  branches/[/quote]


Würde das nicht bedeuten, dass der User, der ggf. mein Programm installiert, nun drei weitere Packages, eines davon mit einem uneindeutigen Namen, in seinen Pythonpath bekommt?
Und wo ich gerade bei Installation bin: gehört die setup.py eurer Meinung nach auch irgendwo in den trunk (wäre also teil des Projekts) oder sollte die eher aussen vor, oder ein eigenes Projekt sein?
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Beitragvon Leonidas » Donnerstag 14. Dezember 2006, 23:42

keppla hat geschrieben:Würde das nicht bedeuten, dass der User, der ggf. mein Programm installiert, nun drei weitere Packages, eines davon mit einem uneindeutigen Namen, in seinen Pythonpath bekommt?

Wieso sollte er das? Er checkt doch in der Regel nur trunk aus, und da hat er zwei Dateien, und einen Ordner. Und sowas checkt man in der Regel nicht in einem Ordner wie site-packaages aus, von daher gibt es an dieser Stelle auch kein Problem mit uneindeutigen Namen.

keppla hat geschrieben:Und wo ich gerade bei Installation bin: gehört die setup.py eurer Meinung nach auch irgendwo in den trunk (wäre also teil des Projekts) oder sollte die eher aussen vor, oder ein eigenes Projekt sein?

Gehört IMHO rein - machen so ziemlich alle mir bekannten Python-Projekte die setup.py überhaupt nutzen.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
Benutzeravatar
keppla
User
Beiträge: 483
Registriert: Montag 31. Oktober 2005, 00:12

Beitragvon keppla » Donnerstag 14. Dezember 2006, 23:52

Wieso sollte er das? Er checkt doch in der Regel nur trunk aus, und da hat er zwei Dateien, und einen Ordner.

Die meinte ich
Und sowas checkt man in der Regel nicht in einem Ordner wie site-packaages aus, von daher gibt es an dieser Stelle auch kein Problem mit uneindeutigen Namen.

Anhand deines Posts vermute ich mal, dass ich da falsch lag, aber ich hatte bisher den Eindruck, dass die meisten Programme, die man installiert, einfach nur ihre eggs in site-packages ablegen, und vielleicht noch irgendwo ein starterskript.

Wer ist online?

Mitglieder in diesem Forum: Bing [Bot], snafu