Wie entwickelt man mehrere Pip-Pakete in einem Git-Projekt?

Question

Ich entwickle ein Django-Projekt, mit Git für das Code-Management. Das Hauptprojekt hat eine Reihe von Apps als Submodule, die jeweils unabhängig voneinander genutzt werden können, also jeweils in separaten Git-Repos. Alle diese Apps sind in der Entwicklung, und mindestens eine wird von einem anderen Projekt gespalten. Diese Apps sind über Pip installierbar, beim Klonen des Repos befinden sich setup.py und README usw. im root, dann die eigentliche App in einem Unterordner.

Wenn ich die App (n) installiere, wird sich der Arbeitscode an einem anderen Ort als der Ordner unter git management befinden, so dass ich jedes Mal, wenn ich den Code ändere, pip install (oder gibt es einen anderen pip Befehl dafür?), um den Code zu aktualisieren, wo Python es sucht

Ich könnte pip install -e verwenden, um die obige Situation zu verhindern. Allerdings müsste ich dann jede App in separate Ordner klonen: Ich kann die Apps nicht einfach in project/apps klonen und habe project/apps/foo und project/apps/bar, da beide versuchen würden, ihre setup.py in project/apps fallen zu lassen. Stattdessen müsste ich foo in project/apps/foo klonen, aber dann ist der tatsächliche Code in project/apps/foo/foo. Das erscheint mir hässlich und nicht sehr django-isch.

Gibt es eine andere, schönere Art zu tun, was ich versuche zu tun?

Answer 1

Ich denke, was Sie wirklich verwenden möchten, ist ein requirements file (anstatt überhaupt git Submodule zu verwenden) gekoppelt mit einem virtualenv für Ihr Projekt.

Mit Anforderungen Dateien können Sie repos direkt aus einem bestimmten Zweig klonen oder begehen, zum Beispiel:

requirements.txt:

Django==1.4.1 
South==0.7.6 
git+git://github.com/fabric/fabric#egg=Fabric 
git+git://github.com/toastdriven/django-tastypie.git@876c0541e2531d3b6e070ffab906f7c6e359c427#egg=django-tastypie 

Dann können Sie pip install -r requirements.txt laufen.

Sie werden am Beispiel von tastypie bemerken, dass Sie Ihre Pip-Installation an einem bestimmten Commit sperren können (solange Sie in Ihrem virtualenv bleiben), was im Grunde das Gleiche ist, was ein Submodul sowieso macht, aber ohne Ihre git Repo- oder Dateistruktur mit Paketen, wenn sie wirklich an einem anderen Ort installiert werden sollten, den Sie sowieso beziehen.