git: Dateidatum der neusten Datei erhalten?

[jens]

So, hab das ganze nochmal geändert. Vorher hatte ich ja den Anfang vom letzten git commit hash an die Versionsnummer geheftet...

Aber was sagt schon eine "zufällige" Zeichenfolge aus? Man kann nicht wirklich leicht erkennen, auf welchen Stand man denn nun ist...

Also nehme ich nun lieber das Datum des letzten commits. Damit kann man doch wesentlich mehr anfangen.

Die Versionsnummer sieht dann z.B. so aus: v0.9.0.RC7.20100827.1442 (Format ist: %Y%m%d.%H%M)
vorher so: v0.9.0.RC6.git-ab3d422

[Leonidas]

Also ich find ja git Hashes jetzt gar nicht so schlecht, ist schließlich die Standardmethode in der Git-Welt einen Zustand des Trees zu markieren.

[jens]

Da hast du schon recht. Mir geht es allerdings mit dem Zusatz in erster Linie darum, schnell zu wissen, auf welchem Stand man so ist. Also wie weit ist die aktuelle Version vom letzten git commit entfernt.

Beim Hash muss man erst mal umständlich recherchieren. Beim Datum hat man direkt eine Vorstellung wie neu oder alt die Version wohl ist...

Da aber sowas wie v0.9.0.RC7.20100827.1442 schon recht lang list, hänge ich seit neustem nur noch Monat und Tag an... Das reicht IMHO aus... Ist beim Jahreswechsel evtl. etwas verwirrend, aber was soll's...

[DasIch]

Das Datum ist aber nicht eindeutig, du solltest auf jedenfall den Hash drin haben.

[lunar]

@DasIch: Bei kleinen Projekten eindeutig genug, um zumindest den groben Stand zu beschreiben.

[jens]

Also ich mache es immer noch so, das ich bei all meinen Projekten das Datum an die Version hänge, siehe: https://github.com/jedie/PyLucid/blob/5 ... _init__.py

Nun hat jemand angemerkt das es Probleme mit pip und "requirements file" gibt: https://github.com/jedie/django-tools/issues/1
Das ist eigentlich ein Bug in pip: https://github.com/pypa/pip/issues/145

Das ganze kommt IMHO daher, das die Versionnummer immer nur das letzte git commit Datum erhält, wenn die sourcen überhaupt noch unter git Verwaltung stehen. Wenn also jemand das Package von PyPi installiert, gibt es kein Datum mehr an die Versionsnummer.

Nun hab ich herraus gefunden, das man doch sowas ähnliches wie svn:keywords und $LastChangedDate$ in git realisieren kann. Stichwörter: .gitattributes clean smudge

Das ganze hier bei http://git-scm.com/book/de/Customizing- ... -Erweitern erklärt.

So müßte man eine "hardcoded" __version__ hin bekommen, oder nicht?

Was haltet ihr davon?

[lunar]

@jens: Gar nichts. Ich halte schon die Idee, automatisiert Versionsnummern – oder zumindest Teile davon – für veröffentlichte Versionen zu vergeben, für falsch. Veröffentliche Versionen müssen stabil sein, und dürfen keinesfalls von der Existenz irgendeines VCS abhängen. Ich halte auch wenig davon, Dateien unter der Kontrolle des VCS automatisch durch das VCS zu verändern, um Versionsnummern einzufügen.

Füge das Datum manuell in die Versionsnummer ein, wenn Du eine neue Version Deines Pakets veröffentlichst. Dann weißt Du, was passiert, und vergibst Versionsnummern bewusst und absichtlich.

[jens]

Es ist keine automatisiert Versionsnummer, sondern nur eine Erweiterung um das letzte commit Datum. Das ist IMHO hilfreich, damit User einordnen können wie alt/neu die Software ist. Das klappt besser als den git SHA-Hash Wert an die Versionsnummer zu hängen.

Ich hab mal was gebastelt: https://github.com/jedie/python-code-sn ... ippets/git

[jens]

So, mit django-tools v0.24.3.0725 bzw. diesen commit: https://github.com/jedie/django-tools/c ... 2e0ec7f75c nutzte ich nun das neue Verfahren um das commit Datum an die versionsnummer zu hängen.

Eigentlich ist es ja sowas wie ein built Datum.

Ich hab nochmal ein paar Bugs gefixed und mehr Informationen in die README gepackt:

https://github.com/jedie/python-code-sn ... ippets/git

[jens]

Ach, wo ich ein wenig unsicher bin ist die Änderung in der setup.py: https://github.com/jedie/django-tools/c ... f75c#L3R13

Also der Teil:

Code: Alles auswählen

if "sdist" in sys.argv or "--version" in sys.argv:
    # update the version string via gitattribute filter
    import subprocess
    subprocess.call(["rm", "django_tools/__init__.py"])
    subprocess.call(["/usr/bin/git", "checkout", "django_tools/__init__.py"])

Ich denke das muß sein, damit auch wirklich das Datum aktuell ist. Denn die Änderungen werden erst nach einem checkout gemacht und dazu muß die Datei am besten auch vorher nicht vorhanden sein...

[lunar]

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

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]

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.

[jens]

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

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!

[deets]

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?

[jens]

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.

[snafu]

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.

[deets]

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.

[snafu]

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.

[jens]

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...

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.

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

[snafu]

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.