Re: [Python-de] Django Portierungstrategy???
HI Sven, hi alle ich habe doch noch eine Frage. Wie geht man am besten vor? Das Requirements.txt hat ca. 20 Eintraege. Wie gehe ich am besten vor, damit ich herausefinde welche packages fuer ein update Django auf 1.6 Sinn machen? Vielen Dank Schoenes Wochenende. schaf Am Mittwoch, 13. April 2016 12:31:03 UTC+2 schrieb Sven Broeckling:
Hi,
Laut gegenwärtigen ReleaseNotes soll das ganz einfach sein. Das Versprechen ist: "wenn dein Quellcode mit der 1.8 warnungsfrei läuft, dann kannst du ohne Probleme auf die 1.11 upgraden". Na ich bin gespannt, ob das so wird. :) Das bin ich auch noch :) Bislang hält mich von Django 1.9 noch u.A. transmeta ab, was ich auch geforked nicht so einfach auf 1.9 gebracht habe. Das greift wohl in die Models ein bevor die Django 1.9 Apps initialisiert sind.
Die jeweiligen Release Notes fassen ja sehr gut zusammen was zu tun ist, wenn ich dann ein Projekt von 1.6 auf 1.8 bringe mache ich das Schritt für Schritt. Python3 ist da leider noch gar kein Thema. u.A. weil requirements noch nicht Python3 tauglich sind. Welche Requirements wären das bei dir? Ist schon ein paar Tage her dass ich das letzte mal einen Branch auf 3 probiert habe, ich meine es wären transmeta, raven (sentry) und pybarcode gewesen. Wobei ich grade gesehen habe dass pybarcode und transmeta jetzt Python 3 unterstützen.
Viele Grüße Sven
On 22.04.2016 16:50, Marcel Hug (schaf) wrote:
HI Sven, hi alle
Welchen Sven meinst du? ;)
ich habe doch noch eine Frage. Wie geht man am besten vor? Das Requirements.txt hat ca. 20 Eintraege. Wie gehe ich am besten vor, damit ich herausefinde welche packages fuer ein update Django auf 1.6 Sinn machen?
Hast du Tests für dein Projekt? Wir gehen üblicherweise so vor: 1) Django-Version anpassen 2) Tests ausführen + Webapplikation manuell testen 3) Logs anschauen, Testergebnisse anschauen 4) Probleme fixen & zurück zu 3) Schritt 4 involviert üblicherweise ReleaseNotes/Dokumentation von Django lesen, und dann Dritt-Anbieter-Projekte (z.B. django-selectable etc.) auf Kompatibilität hin überprüfen. Ggf. entscheiden, ob man bei der Version bleibt, oder das Dritt-Anbieter-Projekt auch upgradet, wenn man gerade diese Baustelle offen hat. vG Sven
Am 22.04.2016 um 16:50 schrieb Marcel Hug (schaf):
HI Sven, hi alle ich habe doch noch eine Frage. Wie geht man am besten vor? Das Requirements.txt hat ca. 20 Eintraege. Wie gehe ich am besten vor, damit ich herausefinde welche packages fuer ein update Django auf 1.6 Sinn machen?
Wie kommen die Einträge in die req.txt? Vermutlich per `pip freeze` .... Dann ist diese Datei wie binärer "Müll" zu betrachten. Als Softwareentwickler willst du mit der Quelldatei arbeiten. Abhängigkeiten werden in Python so weit ich weiß über install_requires in setup.py definiert. Gruß, Thomas -- Thomas Guettler http://www.thomas-guettler.de/
Am 25.04.2016 um 11:45 schrieb Thomas Güttler:
Abhängigkeiten werden in Python so weit ich weiß über install_requires in setup.py definiert.
Jein. install_requires setup.py definiert "abstrakte" Abhängigkeiten. Feste Versionsnummern sind dort nach Möglichkeit zu vermeiden, wenn nötig sollte man darin höchstens Minimal- oder Maximalversionsnummern und direkte Abhängigkeiten festlegen. Die setup,py ist m.E. vorrangig für Python-*Pakete* gedacht. Deswegen sollte man davon ausgehen, dass sie in unterschiedlichen Umgebungen und Nutzungsszenarien ausgeführt wird (z.B. beim Paketbau für Distributionen; beim Entwickler, wenn er sein virtualenv für ein Projekt füllt; beim Testen mit tox usw.) Die requirements.txt ist auf der Projekt bzw. Applikationsebene angesiedelt. In ihr kann man Versionen pinnen und definiert sozusagen die genaue Ausführungsumgebung für die Anwendung. Es sind dort i.d.R. alle notwendigen Pakete, also auch die Abhängigkeiten von Abhängigkeiten (rekursiv) aufgeführt. Es gibt Tools, mit denen man die abstrakten Abhängigkeiten aus der requirements.txt (halb-)automatisch extrahieren kann. Eine naive Implementierung zum Einbinden in die setup.py, die für einfache Fälle ausreicht, habe ich zum Beispiel hier notiert: https://gist.github.com/SpotlightKid/486c711a3c14c70edb1a Besser wäre m.E. aber, ein entsprechendes Skript in den Release-Prozess zu integrieren, das dann auch indirekte Abhängigkeiten bereinigt usw. Weitere Gedanken zum Thema: https://caremad.io/2013/07/setup-vs-requirement/ Gruß, Chris
Am 25.04.2016 um 15:39 schrieb Christopher Arndt:
Am 25.04.2016 um 11:45 schrieb Thomas Güttler:
Abhängigkeiten werden in Python so weit ich weiß über install_requires in setup.py definiert.
Jein. install_requires setup.py definiert "abstrakte" Abhängigkeiten. Feste Versionsnummern sind dort nach Möglichkeit zu vermeiden, wenn nötig sollte man darin höchstens Minimal- oder Maximalversionsnummern und direkte Abhängigkeiten festlegen.
Die setup,py ist m.E. vorrangig für Python-*Pakete* gedacht. Deswegen sollte man davon ausgehen, dass sie in unterschiedlichen Umgebungen und Nutzungsszenarien ausgeführt wird (z.B. beim Paketbau für Distributionen; beim Entwickler, wenn er sein virtualenv für ein Projekt füllt; beim Testen mit tox usw.)
Die requirements.txt ist auf der Projekt bzw. Applikationsebene angesiedelt. In ihr kann man Versionen pinnen und definiert sozusagen die genaue Ausführungsumgebung für die Anwendung. Es sind dort i.d.R. alle notwendigen Pakete, also auch die Abhängigkeiten von Abhängigkeiten (rekursiv) aufgeführt.
Es gibt Tools, mit denen man die abstrakten Abhängigkeiten aus der requirements.txt (halb-)automatisch extrahieren kann. Eine naive Implementierung zum Einbinden in die setup.py, die für einfache Fälle ausreicht, habe ich zum Beispiel hier notiert: https://gist.github.com/SpotlightKid/486c711a3c14c70edb1a
Ich habe das früher auch gemacht. Ich bin bei einer Diskussion auf python-distuils auf das gestoßen: requirements.txt and setup.py serve different purposes, requirements.txt is for an environment, setup.py is for a package. It doesn't make sense for a setup.py to read from a requirement.txt just like it wouldn't make sense for a deb package to read from a Chef cookbook. ... und es stimmt. In setup.py die req.txt einzulesen ist für mich der falsche Weg. Für was also req.txt nehmen? Aus meiner Sicht es super um das als Ergebnis eines CI-Laufs festzuhalten: Mit diesem Paket-Stand sind alle Tests ok. Sicherlich gibt es vieles was damit noch nicht festgezurt ist (Python-Version, Linux, andere Pakete die per RPM/dpkg da sein müssen und per Subprozess aufgerufen werden ...)
Besser wäre m.E. aber, ein entsprechendes Skript in den Release-Prozess zu integrieren, das dann auch indirekte Abhängigkeiten bereinigt usw.
Stimmmt. Was mir bisher fehlt ist der passende Begriff für das, was die req.txt beinhaltet. Im Django-Kontext wird manchmal der Begriff "Project" verwendet. Aber so weit ich weiß gibt es keinen Konsens in der Python-Welt. Gruß, Thomas -- Thomas Guettler http://www.thomas-guettler.de/
participants (4)
-
Christopher Arndt -
Marcel Hug (schaf) -
Sven R. Kunze -
Thomas Güttler