Hallo, bisher kam ich beim Management meines Codes mit virtualenv und entsprechenden Abhängigkeiten aus. Auf Grund gestiegener Komplexität und erhöhtem Automatisierungsanspruch, hab' ich einen genaueren Blick auf buildout geworfen. Probleme bereitet mir das Zusammenspiel zwischen beiden. Ich hab' Hinweise gefunden, daß buildout eigentlich virtualenvs unnötig machen soll, da die generierten Scripte für entsprechende Isolation sorgen sollen. Ebenso habe ich einen Hinweis gefunden, daß dies für Version 2 von buildout nicht mehr gilt. Die Doku geht aber auf den ersten Blick nicht auf Versionsunterschiede ein!? Langer Rede kurzer Sinn: Ich will ein reproduzierbares Deployment aus mehreren Modulen zusammensetzen. Kann mir jemand eine Startorientierung zum aktuellen Stand der Dinge geben? Doku lesen kann ich selbst, aber für ein "big picture" der Optionen wäre ich sehr dankbar. viele Grüße, Achim
Am 10.11.2013 15:14, schrieb Achim Domma:
Hallo,
bisher kam ich beim Management meines Codes mit virtualenv und entsprechenden Abhängigkeiten aus. Auf Grund gestiegener Komplexität und erhöhtem Automatisierungsanspruch, hab' ich einen genaueren Blick auf buildout geworfen. Probleme bereitet mir das Zusammenspiel zwischen beiden. Ich hab' Hinweise gefunden, daß buildout eigentlich virtualenvs unnötig machen soll, da die generierten Scripte für entsprechende Isolation sorgen sollen. Ebenso habe ich einen Hinweis gefunden, daß dies für Version 2 von buildout nicht mehr gilt. Die Doku geht aber auf den ersten Blick nicht auf Versionsunterschiede ein!?
Langer Rede kurzer Sinn: Ich will ein reproduzierbares Deployment aus mehreren Modulen zusammensetzen. Kann mir jemand eine Startorientierung zum aktuellen Stand der Dinge geben? Doku lesen kann ich selbst, aber für ein "big picture" der Optionen wäre ich sehr dankbar.
Hallo Achim, wir haben bei uns in der Firma die gleichen Gedanken. Wir haben nun folgende Umsetzung: - Im Project (dort steht fast nur Konfig) gibt es die requirements.txt - Das Project wird aus dem Repo geholt, requirements.txt wird installiert. - Die Packages haben *keine* requirements.txt sonder Abhängigkeiten in der jeweiligen setup.py - Zusätzlich gibt es EntryPoints die von einem Script aufgerufen werden. Das hat den Vorteil, dass für jedes Package spezifische Dinge ausgeführt werden. - Das Ganze wird zurzeit per Fabric ausgeführt. - Mittels Jenkins werden Systeme automatische aufgesetzt, getestet und wieder entfernt. Alle Packete kommen entweder von unserem PyPi Server oder aus unserem rhodecode Server (git). Keine Pakete werden aus direkt aus dem Internet geholt. Mit Fabric bin ich persönlich nicht glücklich. Es ist nicht viel besser als: ssh user@remotehost "do ugly stuff with the shell" Als nächste möchte ich einen stabilen Branch in unseren Repos haben. Der Branch soll automatisch verwaltet werden: Wenn alle Test ok sind, wird der Branch entsprechend weiter gesetzt. Wäre schön, wenn noch andere verraten wie sie vorgehen. Gruß, Thomas -- Thomas Guettler http://www.thomas-guettler.de/
Hallo Thomas, danke für dein Rückmeldung. Unsere Probleme und Gedanken decken sich wohl ziemlich genau. Ich persönlich kommt mit fabric recht gut klar. Da es nur Pythoncode ist, kann man eigentlich ganz lesbare Automatisierungen schreiben. Aber es deckt natürlich nur ein Teilproblem ab. Meiner Ansicht nach deckt buildout ziemlich genau das ab, was ihr im Moment mit den requirements.txt macht - nur eben mächtiger um auch komplexere Szenarien zu stemmen. Liebe buildout-User, wo seid ihr? ;-) viele Grüße, Achim Am 11.11.2013 um 12:27 schrieb Thomas Guettler:
Am 10.11.2013 15:14, schrieb Achim Domma:
Hallo,
bisher kam ich beim Management meines Codes mit virtualenv und entsprechenden Abhängigkeiten aus. Auf Grund gestiegener Komplexität und erhöhtem Automatisierungsanspruch, hab' ich einen genaueren Blick auf buildout geworfen. Probleme bereitet mir das Zusammenspiel zwischen beiden. Ich hab' Hinweise gefunden, daß buildout eigentlich virtualenvs unnötig machen soll, da die generierten Scripte für entsprechende Isolation sorgen sollen. Ebenso habe ich einen Hinweis gefunden, daß dies für Version 2 von buildout nicht mehr gilt. Die Doku geht aber auf den ersten Blick nicht auf Versionsunterschiede ein!?
Langer Rede kurzer Sinn: Ich will ein reproduzierbares Deployment aus mehreren Modulen zusammensetzen. Kann mir jemand eine Startorientierung zum aktuellen Stand der Dinge geben? Doku lesen kann ich selbst, aber für ein "big picture" der Optionen wäre ich sehr dankbar.
Hallo Achim,
wir haben bei uns in der Firma die gleichen Gedanken.
Wir haben nun folgende Umsetzung:
- Im Project (dort steht fast nur Konfig) gibt es die requirements.txt - Das Project wird aus dem Repo geholt, requirements.txt wird installiert. - Die Packages haben *keine* requirements.txt sonder Abhängigkeiten in der jeweiligen setup.py - Zusätzlich gibt es EntryPoints die von einem Script aufgerufen werden. Das hat den Vorteil, dass für jedes Package spezifische Dinge ausgeführt werden. - Das Ganze wird zurzeit per Fabric ausgeführt. - Mittels Jenkins werden Systeme automatische aufgesetzt, getestet und wieder entfernt.
Alle Packete kommen entweder von unserem PyPi Server oder aus unserem rhodecode Server (git). Keine Pakete werden aus direkt aus dem Internet geholt.
Mit Fabric bin ich persönlich nicht glücklich. Es ist nicht viel besser als:
ssh user@remotehost "do ugly stuff with the shell"
Als nächste möchte ich einen stabilen Branch in unseren Repos haben. Der Branch soll automatisch verwaltet werden: Wenn alle Test ok sind, wird der Branch entsprechend weiter gesetzt.
Wäre schön, wenn noch andere verraten wie sie vorgehen.
Gruß, Thomas
-- Thomas Guettler http://www.thomas-guettler.de/ _______________________________________________ python-de maillist - python-de@python.org https://mail.python.org/mailman/listinfo/python-de
Am 11.11.2013 12:47, schrieb Achim Domma:
Hallo Thomas,
danke für dein Rückmeldung. Unsere Probleme und Gedanken decken sich wohl ziemlich genau. Ich persönlich kommt mit fabric recht gut klar. Da es nur Pythoncode ist, kann man eigentlich ganz lesbare Automatisierungen schreiben. Aber es deckt natürlich nur ein Teilproblem ab. Meiner Ansicht nach deckt buildout ziemlich genau das ab, was ihr im Moment mit den requirements.txt macht - nur eben mächtiger um auch komplexere Szenarien zu stemmen.
Liebe buildout-User, wo seid ihr? ;-)
Hallo Achim, das bin ich leider auch nicht... Aber vielleicht mal etwas zwecks Unterhaltung: m.E. buildout und virtualenv so etwas wie Äpfel und Birnen - die These auch deshalb, da im Netz ein Tutorial etwas anderes behauptet. Soweit ich sehen kann, liefert Virtualenv ist ein schliche Pfad-Manipulation, die dafür sorgt, daß im Zweifel die Dateien des Virtualenv-Verzeichnisses geladen werden, und nicht weiter hinten im Pfad stehende. Das wars dann schon. So weit, Andreas
participants (3)
-
Achim Domma -
Andreas Röhler -
Thomas Guettler