Das deutsche Python-Forum

jens hat geschrieben:Bisher offensichtlich nicht
Git ist Neuland...

Dann brauchst du dich auch nicht wundern, denn ``git describe`` gibt ja ``NEUESTER_TAG-REVISIONS_SEIT_TAG-LETZTER_COMMIT_HASH`` aus. Wenn es keinen Tag gibt, wo sollte dann ``NEUESTER_TAG`` herkommen?

jens hat geschrieben:Bin noch nicht so eingearbeitet in git. Aber 'master' ist der Name des branches und kann sich ändern, oder nicht?

Ja. Aehnlich `default` bei Hg.

Der aktuelle Entwicklungszweig kann sich natürlich ändern, insofern ist es eigentlich nicht wirklich sinnvoll, "master" hart zu kodieren. Sinnvoller ist eigentlich "HEAD", denn das bezieht sich immer auf den Commit, auf dem die Änderungen des Arbeitsverzeichnisses basieren, also der Vater des nächsten Commits.

"git describe" ist natürlich das beste.

Ah. Dann nehme ich ersrnal HEAD statt master,

Wenn "describe" auch ohne tags funktionieren würde, dann wäre ich dabei

jens hat geschrieben:Wenn "describe" auch ohne tags funktionieren würde, dann wäre ich dabei

Tuts doch auch, siehe dessen Dokumentation.

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

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.

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

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

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

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?

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

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

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

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

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

Ich schliesse mich lunar da an. Auf meinem mac zB ist das hier schon ein Problem:
Geht schon nicht mit deinen Sourcen.

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!

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?

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.