git: Dateidatum der neusten Datei erhalten?

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
lunar

Mittwoch 25. Juli 2012, 18:14

@jens: Natürlich ist eine Versionsnummer automatisiert, wenn Teile derselben automatisch erstellt werden… das ist schließlich die Definition von „automatisiert“ :roll:

Wie gut Deine jetzige Lösung funktioniert, kannst Du ausprobieren, indem Du das Repo mal auf einem System ohne angepasste Git-Konfiguration klonst. Dann nämlich ist der "dater"-Filter nicht vorhanden, "$date" wird nicht ersetzt, und jeder Versuch, "setup.py" aufzurufen, schlägt mit einem "IndexError" fehl, weil der reguläre Ausdruck in "django-tools/__init__.py" keine Treffer erzielt. Es gibt kaum bessere Wege, potentielle Helfer zu vergraulen, als das zentrale Installationsskript des Projekts unbrauchbar zu machen… mich jedenfalls schreckt schon diese „Lösung“, die Du da in "setup.py" verwendest, um das Datum aktuell zu halten, ab, und lässt mich schlimmstes vermuten über die Qualität des Quelltexts.

Ich rate Dir nochmals nachdrücklich davon ab, irgendwelche automatisch generierten Bestandteile in die Versionsnummer veröffentlichter Versionen aufzunehmen. Veröffentliche Versionsnummern müssen stabil und für alle Benutzer nachvollziehbar sein. Letzteres bedeutet insbesondere, dass ich das Repo klonen, den Tag der Version auschecken, und die Software installieren kann, ohne dass ich dazu Git besonders konfigurieren, oder überhaupt installieren müsste [1].

Deine Benutzer sind ja (hoffentlich) nicht dumm, und wissen sich sicherlich zu helfen, wenn sie das Alter der installierten Version herausfinden wollen. Ist ja nicht so, als wäre das ein Geheimnis, schließlich lässt sich das Alter einer Version auch über das Datum der Downloads im Cheeseshop, das Datum der Tags auf Github, oder idealerweise über das Changelog des Projekts herausfinden. Wenn Dein Projekt kein Changelog hat, dann wäre jetzt ein guter Zeitpunkt, eines zu schreiben :)

[1]: Man kann durchaus Repos klonen, ohne die "git"-Executable zu installieren. Diverse graphische Git-Frontends (u.a. SourceTree, Github for Windows, und Github for Mac) enthalten eine eingebettetes Git, so dass man zwar aus dem Frontend heraus Git-Befehle ausführen kann, allerdings auf der Kommandozeile kein "git" zur Verfügung hat. Unter Windows wird sogar davon abgeraten, "git" systemweit zur Verfügung zu stellen, da diverse Git-Hilfsprogramme Systemprogramme von Windows überschreiben.
deets

Donnerstag 26. Juli 2012, 08:10

Ich schliesse mich lunar da an. Auf meinem mac zB ist das hier schon ein Problem:

Code: Alles auswählen

tequila:v2 deets$ which git
/opt/local/bin/git
Geht schon nicht mit deinen Sourcen.
Benutzeravatar
jens
Moderator
Beiträge: 8487
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Donnerstag 26. Juli 2012, 08:20

lunar hat geschrieben:Wie gut Deine jetzige Lösung funktioniert, kannst Du ausprobieren, indem Du das Repo mal auf einem System ohne angepasste Git-Konfiguration klonst. Dann nämlich ist der "dater"-Filter nicht vorhanden, "$date" wird nicht ersetzt, und jeder Versuch, "setup.py" aufzurufen, schlägt mit einem "IndexError" fehl...
Das ist mir im Nachhinein auch aufgefallen :(
deets hat geschrieben:tequila:v2 deets$ which git
/opt/local/bin/git
Das ist ebenfalls ein Problem...

Nun könnte ich den IndexError abfangen und die Ausgabe von which nutzten...

Vielleicht ist es aber generell eine bessere Lösung mit einem git pre-commit hook zu arbeiten, denn die Geschichte in der setup.py gefällt mich auch nicht wirklich!

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
deets

Donnerstag 26. Juli 2012, 08:36

Wieso *ueberhaupt* ein Datum mit einer Versionsnummer verknuepfen? Da faengt das Verstaendnisproblem doch schon an. Wozu soll denn das gut sein? Hast du Version 3.1-2012-07-24 und 3.1-2012-07-25? Warum dann nicht gleich 3.2?
Benutzeravatar
jens
Moderator
Beiträge: 8487
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Donnerstag 26. Juli 2012, 09:34

Das ist interessant, wenn man nicht aus dem PyPi das Paket installiert, sondern via "pip install -e". Also direkt die git sourcen nutzt.

Natürlich kann derjenige dann auch per git nachschauen auf welchen Stand er ist.

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
snafu
User
Beiträge: 5901
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Donnerstag 26. Juli 2012, 09:43

Und die Idee mit dem Changelog möchtest du nicht weiter verfolgen? Außerdem ließe sich das Datum der letzten Änderung ja auch einfach so abspeichern. Dafür braucht es nicht unbedingt eine automatische Erzeugung, die abhängig von irgendwelchen externen Programmen (hier: `git`) ist. Das geht also völlig ohne diesen ungewöhnlichen Einbauversuch in die Versionsnummer.
Zuletzt geändert von snafu am Donnerstag 26. Juli 2012, 09:44, insgesamt 1-mal geändert.
deets

Donnerstag 26. Juli 2012, 09:43

Das erklaert mir immer noch nicht, *was* daran genau interessant ist. Das ich jeden Tag ne neue Version installieren kann?

Wir haben hier intern mit diversen utility-paketen aehnlich gearbeitet. Nur wurde es dann doof, wenn man mehrfach am Tag was veraendert hat - dann musste man doch wieder hingehen, den alten Kram deinstallieren, und den neuen drueber-buegeln.

Ich glaube, du kannst dir diese Verrenkungen ersparen. Wer so mit deinen Paketen arbeiten will, der ist gut genug, diese Problemchen selbst zu loesen. Aber du verursachst erstmal eine Menge Komplexitaet fuer alle anderen.
Benutzeravatar
snafu
User
Beiträge: 5901
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Donnerstag 26. Juli 2012, 09:49

Mir würde noch eine Kombination aus allem einfallen: Ein Tupel in der Form `(version, date, commit_tag)` oder so ähnlich. Dies bietet man zusätzlich zur "normalen" Versionsabfrage z.B. als `get_extended_info()` an. `commit_tag` ist dabei `None`, wenn es nicht ermittelt werden konnte (z.B. kein `git`-Repo benutzt). Dieses Tupel könnte man natürlich genau so gut auch fest als Attribut einbauen, also ohne Funktionsaufruf.
Benutzeravatar
jens
Moderator
Beiträge: 8487
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Donnerstag 26. Juli 2012, 10:00

Ja, ihr habt mich überzeugt. Die Verränkungen werden mit doch zu viel. Schade das es nicht einfach die svn:keywords gibt, die problemlos funktionieren...

Ich hab dennoch noch einen pre-commit hook geschrieben: https://github.com/jedie/python-code-sn ... -commit.py

Aber nutzten werde ich den nicht, weil es auch unpraktisch ist: Man macht eine Änderung und comittet irgendwas. Der Hook ändert dann das Datum, aber dann muß man die __init__.py wieder selber comitten. Gut, man könnte im hook selber die Datei mit der __version__ info zum commit packen und so... Aber das ist auch wieder zu undurchsichtig...
snafu hat geschrieben:Und die Idee mit dem Changelog möchtest du nicht weiter verfolgen?
Das mache ich schon. Meist in der README. Nun muss ich mir am besten angewöhnen, das Datum immer dazu zu schreiben.
snafu hat geschrieben:Mir würde noch eine Kombination aus allem einfallen: Ein Tupel in der Form `(version, date, commit_tag)` oder so ähnlich. Dies bietet man zusätzlich zur "normalen" Versionsabfrage z.B. als `get_extended_info()` an. `commit_tag` ist dabei `None`, wenn es nicht ermittelt werden konnte (z.B. kein `git`-Repo benutzt). Dieses Tupel könnte man natürlich genau so gut auch fest als Attribut einbauen, also ohne Funktionsaufruf.
Das hatte ich im Prinzip vorher. Nicht "None", aber wenn Datum nicht ermittelbar ist, dann wird die Stelle einfach leer gelassen, siehe: https://github.com/jedie/django-tools/b ... _init__.py

Wobei ich nicht den git SHA hash genommen habe, weil der erst einmal nichts aussagt. Der User muß dann irgendwo (bsp. bei github) nachschauen um ihn Zeitlich einzuordnen. Also habe ich das Datum genommen. Am besten wäre einen commit counter, wie bei SVN, aber den gib es ja nicht bei git...

Das weglassen, wenn nicht ermittelbar ist jedoch genau das Problem, siehe: https://github.com/jedie/django-tools/issues/1

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
snafu
User
Beiträge: 5901
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Donnerstag 26. Juli 2012, 10:12

Ich sprach davon eine wie auch immer geartete Zeitangabe *nicht* in die Version einzubauen. Dies spricht ja auch der Ersteller des verlinkten Issues an. Der verlinkte Code arbeitet auch mit dem Einbau direkt in die Version. Das Problem ist wie gesagt nicht, solche Dinge generell zu protokollieren bzw leicht zugänglich zu machen, sondern eben die Integration in die Versionsnummer. Du müsstest prinzipiell nur diesen Punkt umbauen, dann sollte es eigentlich funktionieren.

Übrigens meinte ich natürlich nicht `commit_tag`, sondern `commit_hash`. Das Datum kann dir als grobe Einordnung dienen, der Hashwert ist wiederum praktisch für eine exakte Zuordnung.
Benutzeravatar
snafu
User
Beiträge: 5901
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

Donnerstag 26. Juli 2012, 10:20

Achso, und die Angabe eines Commit-Hashs, wenn man einen ganz bestimmten Codestand aus einem Git-Repo haben will, ist mit Pip übrigens auch möglich. Von daher verstehe ich noch weniger warum du hier dein eigenes Süppchen kochen willst...
lunar

Donnerstag 26. Juli 2012, 10:52

@jens: "svn:keywords" funktioniert nur in einer ausschließlich linearen Entwicklung im "trunk" gut, ohne Verzweigungen, ohne externe Einflüsse (i.e. Patches), usw. Ein Merge mit keywords, noch dazu wenn beide Branches unterschiedliche "svn:keywords" haben, funktioniert dagegen keinesfalls „problemlos“…

Ein Changelog gehört imho in eine eigene Datei. Das Changelog von Sphinx kann hier als Vorbild dienen…

Bei "pip install -e" kannst Du das Datum auch ganz ohne Verrenkungen mit "setuptools"-Bordmitteln einfügen. Erstelle eine "setup.cfg" im Verzeichnis von "setup.py" mit folgendem Inhalt:

Code: Alles auswählen

[egg_info]
tag_build = dev
tag_date = true

[aliases]
release = egg_info -RDb ''
Dann hat jede Version, die Du lokal installierst, in den Egg-Metadata das Postfix "dev-$HEUTIGES_DATUM". Bei Release führst Du einfach "python setup.py release sdist upload" aus, um eine Version ohne Postfix zu erstellen.
Antworten