Das deutsche Python-Forum

Hallo,

da ich relativ oft neue Versionen meiner Programme ausliefere, möchte ich - auch um mit den Nutzern eine gemeinsame Sprache sprechen zu können - gerne Versionsnummern oder besser noch die Revisionsnummern von Mercurial (ggf. auch die Tags) in den Programmcode integrieren. Ob das jetzt in Form einer separaten Datei oder wirklich direkt im Code passiert, ist mir erstmal egal. Es soll nur sichergestellt sein, daß auf jeden Fall diese Versionsinformation enthalten ist - egal, ob ich einen checkout aus dem Hauptrepo mache (=.hg/ vorhanden), oder ob ich eine mittels hg archive erstellte Kopie (.hg/ nicht vorhanden) verwende.

Im Moment ändere ich alle paar commits einen Versionsstring per Hand und pflege ihn dann per commit ein. Das Problem damit: Es ist vergleichsweise aufwändig, ich vergesse es gerne mal, und es ist nicht immer so präzise wie ich es gerne hätte.

Ich habe bereits mit precommit-Hooks experimentiert, und auch eine Hg-Erweiterung getestet, die Platzhalter ersetzen kann. Das Problem ist bei allen diesen Ansätzen, daß die Aktualisierung des Versionsstrings ja wieder eine Änderung darstellt, die sich aber nicht einfach so einchecken läßt. Vor allem ist der Versionsstring nach Einchecken der Aktualisierung ja auch schon wieder obsolet. Ich bin mir nicht sicher, ob das VCS überhaupt der richtige Ort für derartige Aktionen ist. An einer Stelle wurde vorgeschlagen, diese Aufgabe vom Build-System erledigen zu lassen - nur nutze ich bislang keines.

Wie würdet ihr mit dieser Problemstellung umgehen? Wo könnte ich ansetzen?

Nimm doch einen post-commit-hook, der z.B. eine Datei "version.txt" erzeugt, in der dann der aktuelle Hash eingetragen wird. Die Datei nimmst du aus der Versionsverwaltung heraus, dann entsteht auch keine neue Änderung, die du erneut committen müsstest. In deiner Anwendung liest du dann den Inhalt von "version.txt" und kannst den Hash als Versionsnummer anzeigen.

Stefan

Vielen Dank für deine Antwort, aber wenn ich die Datei aus der Versionsverwaltung rausnehme, wird sie leider nicht mehr mit ausgeliefert, wenn ich aus dem Repo auschecke.

Ich persönlich baue Manpages mit Make, M4 und den Versionsnummern aus Git (``git describe``, guter Tipp von Defnull). Die Leute die kein ``.git`` haben, ignoriere ich aus praktischen Gründen. Könnte eigentlich auch ein Make-Target machen, dass die Version irgendwie aus Git exportiert und in eine Datei schreibt, diese in einen "Release-Tarball" reinsetzt und so, aber ich habe es einfach bisher nicht für notwendig gehalten.

Ich handhabe das wie Leonidas, die Changeset Id wird beim build definiert/einkompiliert. Im Falle von Python ist das dann eben beim bauen des Release Tarballs/Eggs. Im einfachsten Fall: hg log -r1 --template 'HGNODE = "{node}"\n' > hgnode.py

Es gibt jetzt auch hgdistver.

Vielen Dank erst einmal für die doch recht zahlreichen Anregungen.

Ich bin mir noch nicht ganz schlüssig, welchen Weg ich beschreiten möchte. Es wird aber wohl auf eine Routine hinauslaufen, die das Erstellen einer Versionsdatei und das anschließende Packen für mich übernimmt. Das Programm wird dann zunächst nach dieser Versionsdatei suchen, und, falls es diese nicht findet, nach einem Unterverzeichnis .hg . Bleibt noch die Frage, wie viel Aufwand der Zusatznutzen rechtfertigt. Wenn ich an das Pareto-Prinzip denke, sollte ich mir wohl nicht mehr allzu viele Gedanken machen