Ich habe mehrere Python-Projekte mit gemeinsamen Modulen. Bis jetzt war ich ... ähem ... mehrere Kopien des gemeinsamen Codes zu behalten und von Hand zu synchronisieren. Aber ich würde eindeutig lieber etwas anderes machen.
Es sieht für mich jetzt so aus, als ob zc.Buildout vielleicht das ist, was ich brauche. Ich denke, was ich tun sollte, ist, jede wiederverwendbare Komponente meines Systems in ein separates Ei zu legen und dann Buildout zu verwenden, um sie zu Projekten zusammenzufügen.
Ich denke auch, dass ich für ein bestimmtes Modul die Komponententests in ein separates Paket oder Ei legen sollte, damit ich nicht auch Kopien der Komponententests in jedes Projekt installiere. Ich möchte nur Unit-Tests an Orten durchführen, an denen meine Bibliothek entwickelt wird, nicht dort, wo sie gerade verwendet werden.
Vielleicht möchte ich so etwas haben
%Vor%usw.
Dabei sind sowohl app1 als auch app2 unabhängige Anwendungen mit eigenem Code und eigenen Tests, enthalten aber auch lib1 und lib2. Und lib1 / test, lib1 / code, lib2 / test, lib2code, app1, app2 sind getrennte Eier. Klingt das richtig?
Allerdings werde ich jetzt verwirrt. Ich gehe davon aus, dass ich bei der Entwicklung von app1 Buildouts verwenden möchte, um Kopien von lib1, lib2 und app1 in ein separates Arbeitsverzeichnis zu ziehen, anstatt Kopien dieser Bibliotheken direkt unter app1 abzulegen. Aber wie funktioniert das mit meiner SVN-Quellcodeverwaltung? Wenn das Arbeitsverzeichnis dynamisch mit Buildout erstellt wird, kann es kein Live-SVN-Verzeichnis sein, aus dem ich die Änderungen zurück in das Repository überprüfen kann?
Habe ich missverstanden, wie Buildout verwendet werden soll? Wäre ich besser für einen ganz anderen Ansatz? Wie mischt man Quellcodeverwaltung mit Modulwiederverwendung zwischen Projekten?
Update: Danke an die zwei Leute, die diese Frage beantwortet haben. Ich experimentiere mehr damit.
Trennen Sie die Tests nicht von Ihrem Code, Sie müssen die beiden eng beieinander halten. Es ist nicht so, als würden Tests so viel Speicherplatz oder Speicher beanspruchen! Und Tests können für Ihre Bibliotheksbenutzer äußerst aufschlussreich sein.
Fügen Sie bei Bibliothekspaketen eine buildout.cfg - und bootstrap.py -Datei in Ihr Paket ein, damit die Tests einfach ausgeführt werden können. Siehe zum Beispiel das Paket plone.reload ; Beachten Sie, wie es zc.recipe.testrunner Teile verwendet, um ein Testskript zu erstellen, das Ihre Tests automatisch erkennt und führe sie aus. Auf diese Weise können Sie sicherstellen, dass Ihre Bibliothekspakete immer getestet werden!
Dann müssen Ihre App-Pakete nur den integrations- und anwendungsspezifischen Code testen. Fügen Sie die Tests mit dem Paket selbst wieder hinzu, Sie möchten Ihre Tests nicht vergessen, wenn Sie an dem Code arbeiten. Verwenden Sie zc.recipe.testrunner Teile in Ihrem Buildout, um diese zu erkennen und auszuführen.
Verwenden Sie mr.developer , um Ihre Pakete zu verwalten. Mit Mr.Developer können Sie Pakete als Ihre Arbeit an ihnen auschecken oder auf die freigegebenen Versionen zurückgreifen, wenn Sie nicht an dem Code arbeiten müssen. Ein größeres Projekt wird viele Abhängigkeiten haben, von denen viele den Code nicht optimieren müssen. Mit mr.developer können Sie Quellcode nach Belieben einlesen und in Entwicklungs-Eizellen umwandeln, bis Sie diesen Code freigeben und die Kasse wieder verlassen können.
Um ein Beispiel für ein solches Projekt-Buildout zu sehen, suchen Sie nicht weiter als Plone-Core-Entwicklung .
Die Datei sources.cfg enthält eine lange Liste von SCM-Speicherorten für verschiedene Pakete, aber normalerweise werden freigegebene Versionen von Eizellen verwendet, bis Sie explizit die Pakete aktivieren, an denen Sie arbeiten möchten. checkouts.cfg listet alle Pakete auf, die standardmäßig ausgecheckt wurden. Diese Pakete haben Änderungen, die Teil der nächsten Version von Plone sein werden und noch nicht veröffentlicht wurden. Wenn Sie an Plone arbeiten, möchten Sie diese, weil Sie diese Änderungen nicht ignorieren können. Und testing.cfg listet alle Pakete auf, die Sie testen müssen, wenn Sie Plone, eine große Liste, testen wollen.
Beachten Sie, dass die Quellen von Plone aus einer Vielzahl von Orten stammen. Sobald Sie anfangen, Buildout und Mr.Developer zu verwenden, um Ihre Pakete zu verwalten, können Sie Ihren Quellcode von überall abrufen.
Aus diesem Grund haben Sie das Website -Modul. Es setzt das interne sys.path auf alle Pakete und Module von
lib/site-packages - einschließlich Verzeichnisse, Eier und .pth Dateien. PYTHONPATH Auf diese Weise gibt es genau eine Arbeitskopie Ihrer Bibliotheken.
Es gibt unbegrenzte Möglichkeiten, dies zu nutzen. Hier sind zwei.
Schreibe in jede lib ein setup.py , das deine lib richtig einsetzt. Wenn Sie Änderungen vornehmen, führen Sie ein svn up zum Erfassen der Änderungen und ein python setup.py install zum Bereitstellen der einen Arbeitskopie durch, die von jeder Anwendung freigegeben wird.
In jeder App hängt es von Dingen ab, die sich in der Umgebungsvariable PYTHONPATH befinden. Stellen Sie sicher, dass projects/lib1 und projects/lib2 die PYTHONPATH gewonnen haben. Jede App teilt dann die eine Arbeitskopie der verschiedenen Bibliotheken.
Ich habe die folgende Struktur sehr effektiv verwendet. in SVN.
%Vor%Ich würde dann meinen dev-Arbeitsbereich (ich benutze eclipse / pydev) wie folgt erstellen, indem ich entweder aus dem Stamm oder einem Zweig auschecke.
%Vor%Ich würde dann entweder den Eclipse-Projektabhängigkeiten-Setup-Python-Pfad verwenden, der gut mit der Eclipse-Code-Vervollständigung funktioniert. setup.py funktioniert auch, unterstützt jedoch nicht mehrere Arbeitsbereiche.
Für die Bereitstellung verwende ich eine einzelne Zip-Datei mit der folgenden Struktur:
%Vor%Ich verwende keine Setup-Installation, da ich mehrere Versionen der App unterstützen möchte, außerdem habe ich etwas Kontrolle über die Laufzeitumgebung, daher packe ich Python nicht mit meiner Implementierung, sollte aber leicht Python hinzufügen Bereitstellungspaket, wenn es benötigt wird.
Ich würde jede Anwendung und Bibliothek ein Ei betrachten und eines der Beispiele verwenden, die bereits gegeben wurden, um es in SVN auszulegen. Wirklich, das VCS-Ende der Dinge sollte kein Problem sein.
Dann, zum Testen jeder Anwendung / Bibliothek oder Kombination, würde ich ein virtualenv einrichten und jedes Paket entweder über setup.py develop oder über die eigentliche Installation installieren. Virtualenvwrapper ist auch ein hilfreiches Werkzeug, um diese Umgebungen zu verwalten, da Sie einfach Dinge tun können wie:
%Vor%Und später:
%Vor%Virtualenv verwendet den PYTHONPATH, um eine bessere Kontrolle über die installierten Pakete zu erhalten. Ebenso können Sie create-Umgebungen mit folgenden Elementen verwenden:
%Vor%Und es werden alle Verweise auf Ihre tatsächlichen System-Site-Pakete weggelassen. Dies ist hilfreich, da Sie nicht nur Ihre Bibliothek / Anwendung testen können, sondern auch überprüfen können, ob Sie die richtigen Abhängigkeiten von der Installation haben.
Tags und Links python svn egg code-organization buildout