Das deutsche Python-Forum

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"

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.

Wäre es nicht so sinnvoller?Sonst muss man client und server getrennt auschecken und auchnoch dafür Sorge tragen, dass man immer zueinander kompatible Versionen auscheckt/taggt/etc.

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/

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.

Erstmal danke für die Antworten.
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?

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.

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.