Standardmethode zum Einbetten der Version in das Python-Paket?

Gibt es eine Standardmethode, um Versionszeichenfolgen einem Python-Paket so zuzuordnen, dass ich Folgendes tun kann?

import foo
print foo.version

Ich würde mir vorstellen, dass es eine Möglichkeit gibt, diese Daten ohne zusätzliche Hardcodierung abzurufen, da bereits kleinere / größere Zeichenfolgen angegeben sind setup.py. Alternative Lösung, die ich gefunden habe, war import __version__in meinem zu haben foo/__init__.pyund dann von __version__.pygeneriert zu haben setup.py.

Keine direkte Antwort auf Ihre Frage, aber Sie sollten in Betracht ziehen, sie zu benennen __version__, nicht version.

Dies ist fast ein Quasi-Standard. Viele Module in der Standardbibliothek werden verwendet __version__, und dies wird auch in Losen verwendet Modulen von Drittanbietern verwendet, sodass dies der Quasi-Standard ist.

Normalerweise __version__ist es eine Zeichenfolge, aber manchmal ist es auch ein Float oder Tupel.

Edit: Wie von S.Lott erwähnt (Danke!), Sagt PEP 8 es explizit:

Modul Level Dunder Namen

Modulebene „dunders“ (dh Namen mit zwei führenden und zwei hinteren Unterstrichen) wie __all__, __author__, __version__usw. sollte nach dem Modul docstring gestellt werden , sondern vor all Import - Anweisungen mit Ausnahme von __future__Importen.

Sie sollten auch sicherstellen, dass die Versionsnummer dem in PEP 440 beschriebenen Format entspricht ( PEP 386 eine frühere Version dieses Standards).

Ich verwende eine einzelne _version.pyDatei als "einmal kanonischen Ort", um Versionsinformationen zu speichern:

1. Es bietet ein __version__Attribut.

2. Es bietet die Standard-Metadatenversion. Daher wird es von pkg_resourcesoder anderen Tools erkannt , die die Paketmetadaten analysieren (EGG-INFO und / oder PKG-INFO, PEP 0345).

3. Beim Erstellen Ihres Pakets wird Ihr Paket (oder etwas anderes) nicht importiert, was in einigen Situationen zu Problemen führen kann. (In den Kommentaren unten erfahren Sie, welche Probleme dies verursachen kann.)

4. Es gibt nur einen Ort, an dem die Versionsnummer notiert wird. Es gibt also nur einen Ort, an dem sie geändert werden kann, wenn sich die Versionsnummer ändert, und es besteht eine geringere Wahrscheinlichkeit für inkonsistente Versionen.

So funktioniert es: Der "einzige kanonische Ort" zum Speichern der Versionsnummer ist eine .py-Datei mit dem Namen "_version.py", die sich in Ihrem Python-Paket befindet, z. B. in myniftyapp/_version.py. Diese Datei ist ein Python-Modul, aber Ihre setup.py importiert sie nicht! (Das würde Feature 3 zunichte machen.) Stattdessen weiß Ihre setup.py, dass der Inhalt dieser Datei sehr einfach ist, etwa:

__version__ = "3.6.5"

Und so öffnet Ihre setup.py die Datei und analysiert sie mit Code wie:

import re
VERSIONFILE="myniftyapp/_version.py"
verstrline = open(VERSIONFILE, "rt").read()
VSRE = r"^__version__ = ['\"]([^'\"]*)['\"]"
mo = re.search(VSRE, verstrline, re.M)
if mo:
    verstr = mo.group(1)
else:
    raise RuntimeError("Unable to find version string in %s." % (VERSIONFILE,))

Dann übergibt Ihre setup.py diese Zeichenfolge als Wert des Arguments "version" an setup()und erfüllt damit Merkmal 2.

Um Funktion 1 zu erfüllen, können Sie Ihr Paket (zur Laufzeit, nicht zur Setup-Zeit!) Die _Versionsdatei myniftyapp/__init__.pywie folgt importieren lassen :

from _version import __version__

Hier ist ein Beispiel für diese Technik , die ich seit Jahren verwende.

Der Code in diesem Beispiel ist etwas komplizierter, aber das vereinfachte Beispiel, das ich in diesen Kommentar geschrieben habe, sollte eine vollständige Implementierung sein.

Hier ist ein Beispielcode zum Importieren der Version .

Wenn Sie etwas falsch mit diesem Ansatz sehen, lassen Sie es mich bitte wissen.

Umgeschrieben 2017-05

Nachdem ich mehr als zehn Jahre Python-Code geschrieben und verschiedene Pakete verwaltet hatte, kam ich zu dem Schluss, dass DIY möglicherweise nicht der beste Ansatz ist.

Ich habe angefangen, pbrpackage für die Versionsverwaltung in meinen Paketen zu verwenden. Wenn Sie git als SCM verwenden, passt dies wie von Zauberhand in Ihren Workflow und spart Ihnen wochenlange Arbeit (Sie werden überrascht sein, wie komplex das Problem sein kann).

Bis heute ist pbr die Nummer 11 der am häufigsten verwendeten Python-Pakete, und das Erreichen dieses Levels beinhaltete keine schmutzigen Tricks: war nur eine: Beheben eines häufigen Verpackungsproblems auf sehr einfache Weise.

pbr kann mehr von der Paketwartungslast übernehmen, ist nicht auf die Versionierung beschränkt, zwingt Sie jedoch nicht dazu, alle Vorteile zu nutzen.

Um Ihnen eine Vorstellung davon zu geben, wie es aussieht, pbr in einem Commit zu übernehmen, werfen Sie einen Blick auf pbr

Wahrscheinlich haben Sie festgestellt, dass die Version überhaupt nicht im Repository gespeichert ist. PBR erkennt es an Git-Zweigen und -Tags.

Sie müssen sich keine Gedanken darüber machen, was passiert, wenn Sie kein Git-Repository haben, da pbr die Version beim Packen oder Installieren der Anwendungen "kompiliert" und zwischenspeichert, sodass keine Laufzeitabhängigkeit von Git besteht.

Alte Lösung

Hier ist die beste Lösung, die ich bisher gesehen habe, und sie erklärt auch, warum:

Innen yourpackage/version.py:

# Store the version here so:
# 1) we don't load dependencies by storing it in __init__.py
# 2) we can import it in setup.py for the same reason
# 3) we can import it into your module module
__version__ = '0.12'

Innen yourpackage/__init__.py:

from .version import __version__

Innen setup.py:

exec(open('yourpackage/version.py').read())
setup(
    ...
    version=__version__,
    ...

Wenn Sie einen anderen Ansatz kennen, der besser zu sein scheint, lassen Sie es mich wissen.

Gemäß dem zurückgestellten PEP 396 (Modulversionsnummern) wird ein Weg vorgeschlagen, dies zu tun. Es beschreibt mit Begründung einen (zugegebenermaßen optionalen) Standard für Module, die folgen sollen. Hier ist ein Ausschnitt:

3) Wenn ein Modul (oder Paket) eine Versionsnummer enthält, MUSS die Version im __version__Attribut verfügbar sein .

4) Für Module, die sich in einem Namespace-Paket befinden, sollte das Modul das __version__Attribut enthalten. Das Namespace-Paket selbst sollte kein eigenes __version__Attribut enthalten.

5) Der __version__Wert des Attributs sollte eine Zeichenfolge sein.

Obwohl dies wahrscheinlich viel zu spät ist, gibt es eine etwas einfachere Alternative zur vorherigen Antwort:

__version_info__ = ('1', '2', '3')
__version__ = '.'.join(__version_info__)

(Und es wäre ziemlich einfach, automatisch inkrementierende Teile von Versionsnummern mit in eine Zeichenfolge zu konvertieren str() .)

Nach allem, was ich gesehen habe, neigen die Leute dazu, bei der Verwendung so etwas wie die zuvor erwähnte Version zu verwenden __version_info__und es als solches als Tupel von Ints zu speichern. Ich verstehe dies jedoch nicht ganz, da ich bezweifle, dass es Situationen gibt, in denen Sie mathematische Operationen wie Addition und Subtraktion von Teilen von Versionsnummern für einen anderen Zweck als Neugier oder automatische Inkrementierung ausführen würden (und selbst dann) int()und str()kann ziemlich einfach verwendet werden). (Andererseits besteht die Möglichkeit, dass der Code eines anderen ein numerisches Tupel anstelle eines Zeichenfolgentupels erwartet und somit fehlschlägt.)

Dies ist natürlich meine eigene Ansicht, und ich würde gerne die Beiträge anderer zur Verwendung eines numerischen Tupels begrüßen.

Wie Shezi mich erinnerte, haben (lexikalische) Vergleiche von Zahlenfolgen nicht unbedingt das gleiche Ergebnis wie direkte numerische Vergleiche. Dazu wären führende Nullen erforderlich. Am Ende __version_info__würde das Speichern (oder wie auch immer es genannt werden würde) als Tupel ganzzahliger Werte effizientere Versionsvergleiche ermöglichen.

Viele dieser Lösungen hier ignorieren gitVersions-Tags, was bedeutet, dass Sie die Version an mehreren Stellen verfolgen müssen (schlecht). Ich ging dies mit folgenden Zielen an:

• Leiten Sie alle Python-Versionsreferenzen von einem Tag in der ab git Repo ab
• Automatisieren Sie git tag/ pushund setup.py uploadSchritte mit einem einzigen Befehl, der keine Eingaben akzeptiert.

Wie es funktioniert:

1. Aus einem make releaseBefehl heraus wird die zuletzt getaggte Version im Git-Repo gefunden und erhöht. Das Tag wird zurückgeschoben origin.

2. Das Makefilespeichert die Version dort, src/_version.pywo sie gelesen wird setup.pyund auch in der Version enthalten ist. Nicht _version.pyin die Quellcodeverwaltung einchecken !

3. setup.pyBefehl liest die neue Versionszeichenfolge aus package.__version__.

Einzelheiten:

Makefile

# remove optional 'v' and trailing hash "v1.0-N-HASH" -> "v1.0-N"
git_describe_ver = $(shell git describe --tags | sed -E -e 's/^v//' -e 's/(.*)-.*/\1/')
git_tag_ver      = $(shell git describe --abbrev=0)
next_patch_ver = $(shell python versionbump.py --patch $(call git_tag_ver))
next_minor_ver = $(shell python versionbump.py --minor $(call git_tag_ver))
next_major_ver = $(shell python versionbump.py --major $(call git_tag_ver))

.PHONY: ${MODULE}/_version.py
${MODULE}/_version.py:
    echo '__version__ = "$(call git_describe_ver)"' > $@

.PHONY: release
release: test lint mypy
    git tag -a $(call next_patch_ver)
    $(MAKE) ${MODULE}/_version.py
    python setup.py check sdist upload # (legacy "upload" method)
    # twine upload dist/*  (preferred method)
    git push origin master --tags

Das releaseZiel erhöht immer die Ziffer der 3. Version, aber Sie können das next_minor_veroder verwenden, next_major_verum die anderen Ziffern zu erhöhen. Die Befehle basieren auf dem versionbump.pySkript, das im Stammverzeichnis des Repos eingecheckt ist

versionbump.py

"""An auto-increment tool for version strings."""

import sys
import unittest

import click
from click.testing import CliRunner  # type: ignore

__version__ = '0.1'

MIN_DIGITS = 2
MAX_DIGITS = 3


@click.command()
@click.argument('version')
@click.option('--major', 'bump_idx', flag_value=0, help='Increment major number.')
@click.option('--minor', 'bump_idx', flag_value=1, help='Increment minor number.')
@click.option('--patch', 'bump_idx', flag_value=2, default=True, help='Increment patch number.')
def cli(version: str, bump_idx: int) -> None:
    """Bumps a MAJOR.MINOR.PATCH version string at the specified index location or 'patch' digit. An
    optional 'v' prefix is allowed and will be included in the output if found."""
    prefix = version[0] if version[0].isalpha() else ''
    digits = version.lower().lstrip('v').split('.')

    if len(digits) > MAX_DIGITS:
        click.secho('ERROR: Too many digits', fg='red', err=True)
        sys.exit(1)

    digits = (digits + ['0'] * MAX_DIGITS)[:MAX_DIGITS]  # Extend total digits to max.
    digits[bump_idx] = str(int(digits[bump_idx]) + 1)  # Increment the desired digit.

    # Zero rightmost digits after bump position.
    for i in range(bump_idx + 1, MAX_DIGITS):
        digits[i] = '0'
    digits = digits[:max(MIN_DIGITS, bump_idx + 1)]  # Trim rightmost digits.
    click.echo(prefix + '.'.join(digits), nl=False)


if __name__ == '__main__':
    cli()  # pylint: disable=no-value-for-parameter

Dies macht das schwere Heben, wie die Versionsnummer von verarbeitet und erhöht wird git.

__init__.py

Die my_module/_version.pyDatei wird in importiert my_module/__init__.py. Fügen Sie hier eine statische Installationskonfiguration ein, die Sie mit Ihrem Modul verteilen möchten.

from ._version import __version__
__author__ = ''
__email__ = ''

setup.py

Der letzte Schritt besteht darin, die Versionsinformationen aus dem my_moduleModul zu lesen .

from setuptools import setup, find_packages

pkg_vars  = {}

with open("{MODULE}/_version.py") as fp:
    exec(fp.read(), pkg_vars)

setup(
    version=pkg_vars['__version__'],
    ...
    ...
)

Damit dies alles funktioniert, muss Ihr Repo mindestens ein Versions-Tag enthalten, um zu starten.

git tag -a v0.0.1

Ich verwende eine JSON-Datei im Paketverzeichnis. Dies entspricht den Anforderungen von Zooko.

Innen pkg_dir/pkg_info.json:

{"version": "0.1.0"}

Innen setup.py:

from distutils.core import setup
import json

with open('pkg_dir/pkg_info.json') as fp:
    _info = json.load(fp)

setup(
    version=_info['version'],
    ...
    )

Innen pkg_dir/__init__.py:

import json
from os.path import dirname

with open(dirname(__file__) + '/pkg_info.json') as fp:
    _info = json.load(fp)

__version__ = _info['version']

Ich habe auch andere Informationen pkg_info.jsonwie den Autor eingegeben. Ich verwende gerne JSON, weil ich die Verwaltung von Metadaten automatisieren kann.

Erwähnenswert ist auch, dass dies __version__nicht nur ein Semi-Standard ist. In Python ist __version_info__das also ein Tupel. In den einfachen Fällen können Sie einfach so etwas tun:

__version__ = '1.2.3'
__version_info__ = tuple([ int(num) for num in __version__.split('.')])

... und Sie können die __version__Zeichenfolge aus einer Datei oder was auch immer erhalten.

Es scheint keine Standardmethode zum Einbetten einer Versionszeichenfolge in ein Python-Paket zu geben. Die meisten Pakete, die ich gesehen habe, verwenden eine Variante Ihrer Lösung, z. B. eitner

1. Betten Sie die Version ein setup.pyund setup.pygenerieren Sie ein Modul (z. B. version.py), das nur Versionsinformationen enthält, die von Ihrem Paket importiert wurden, oder

2. Das Gegenteil: Fügen Sie die Versionsinformationen in Ihr Paket selbst ein und importieren Sie diese , um die Version festzulegen setup.py

Pfeil behandelt es auf interessante Weise.

Jetzt (seit 2e5031b )

In arrow/__init__.py:

__version__ = 'x.y.z'

In setup.py:

from arrow import __version__

setup(
    name='arrow',
    version=__version__,
    # [...]
)

Vor

In arrow/__init__.py:

__version__ = 'x.y.z'
VERSION = __version__

In setup.py:

def grep(attrname):
    pattern = r"{0}\W*=\W*'([^']+)'".format(attrname)
    strval, = re.findall(pattern, file_text)
    return strval

file_text = read(fpath('arrow/__init__.py'))

setup(
    name='arrow',
    version=grep('__version__'),
    # [...]
)

Ich habe auch einen anderen Stil gesehen:

>>> django.VERSION
(1, 1, 0, 'final', 0)

Verwenden von setuptoolsundpbr

Es gibt keine Standardmethode zum Verwalten der Version, aber die Standardmethode zum Verwalten Ihrer Pakete ist setuptools .

Die beste Lösung, die ich insgesamt für die Verwaltung der Version gefunden habe, ist die Verwendung setuptoolsmit dempbr Erweiterung. Dies ist jetzt meine Standardmethode zum Verwalten der Version.

Das Einrichten Ihres Projekts für die vollständige Verpackung kann für einfache Projekte übertrieben sein. Wenn Sie jedoch die Version verwalten müssen, sind Sie wahrscheinlich auf der richtigen Ebene, um einfach alles einzurichten. Dadurch wird Ihr Paket auch bei PyPi freigegeben kann sodass jeder es herunterladen und mit Pip verwenden kann.

PBR verschiebt die meisten Metadaten aus den setup.pyTools in eine setup.cfgDatei, die dann als Quelle für die meisten Metadaten verwendet wird, einschließlich der Version. Auf diese Weise können die Metadaten bei Bedarf in eine ausführbare Datei gepackt pyinstallerwerden (falls ja, benötigen Sie wahrscheinlich diese Informationen ), und die Metadaten werden von den anderen Paketverwaltungs- / Setup-Skripten getrennt. Sie können die Versionszeichenfolge direkt setup.cfgmanuell aktualisieren , und sie wird in die Datei gezogen*.egg-info Erstellen Ihrer Paketversionen Ordner . Ihre Skripte können dann mit verschiedenen Methoden aus den Metadaten auf die Version zugreifen (diese Prozesse werden in den folgenden Abschnitten beschrieben).

Wenn Sie Git für VCS / SCM verwenden, ist dieses Setup sogar noch besser, da viele Metadaten von Git abgerufen werden, sodass Ihr Repo Ihre primäre Wahrheitsquelle für einige der Metadaten sein kann, einschließlich Version, Autoren, Änderungsprotokolle, usw. Für die spezifische Version wird eine Versionszeichenfolge für das aktuelle Commit basierend auf den Git-Tags im Repo erstellt.

• PyPA - Python-Pakete mit SetupTools verpacken - Tutorial
• Dokumentation zur neuesten Verwendung von PBR - Einrichten einer 8-Zeilen- Dokumentationsetup.py und einer setup.cfgDatei mit den Metadaten.

Da PBR Version, Autor, Änderungsprotokoll und andere Informationen direkt aus Ihrem Git-Repo abruft, sind einige der Metadaten in setup.cfg und automatisch generiert werden, wenn eine Distribution für Ihr Paket erstellt wird (mithilfe von setup.py).

Aktuelle Echtzeitversion

setuptools wird die neuesten Informationen in Echtzeit mit abrufen setup.py :

python setup.py --version

Dadurch wird die neueste Version entweder aus dem setup.cfg Datei oder aus dem Git-Repo abgerufen, basierend auf dem zuletzt vorgenommenen Commit und den im Repo vorhandenen Tags. Dieser Befehl aktualisiert die Version in einer Distribution jedoch nicht.

Aktualisierung der Version

Wenn Sie eine Distribution mit setup.py( py setup.py sdistz. B.) erstellen , werden alle aktuellen Informationen extrahiert und in der Distribution gespeichert. Dies führt im Wesentlichen den setup.py --versionBefehl aus und speichert diese Versionsinformationen in dem package.egg-infoOrdner in einer Reihe von Dateien, in denen Verteilungsmetadaten gespeichert sind.

Hinweis zum Aktualisieren der Versionsmetadaten:

Wenn Sie pbr nicht zum Abrufen von Versionsdaten aus git verwenden, aktualisieren Sie einfach Ihre setup.cfg direkt mit neuen Versionsinformationen (einfach genug, aber stellen Sie sicher, dass dies ein Standardbestandteil Ihres Veröffentlichungsprozesses ist).

Wenn Sie git verwenden und keine Quell- oder Binärdistribution (mit python setup.py sdistoder einem der python setup.py bdist_xxxBefehle) erstellen müssen, können Sie die git-Repo-Informationen am einfachsten in Ihrem <mypackage>.egg-infoMetadatenordner aktualisieren, indem Sie einfach den python setup.py installBefehl ausführen . Dadurch werden alle PBR-Funktionen ausgeführt, die sich auf das Abrufen von Metadaten aus dem Git-Repo beziehen, Ihren lokalen .egg-infoOrdner aktualisieren , ausführbare Skriptdateien für alle von Ihnen definierten Einstiegspunkte installieren und andere Funktionen, die Sie in der Ausgabe sehen können, wenn Sie diesen Befehl ausführen.

Beachten Sie, dass der .egg-infoOrdner im Allgemeinen nicht im Git-Repo selbst in Standard-Python- .gitignoreDateien (z. B. von Gitignore.IO ) gespeichert werden kann , da er aus Ihrer Quelle generiert werden kann. Wenn dies ausgeschlossen ist, stellen Sie sicher, dass Sie über einen Standard- "Freigabeprozess" verfügen, um die Metadaten vor der Veröffentlichung lokal zu aktualisieren. Jedes Paket, das Sie auf PyPi.org hochladen oder auf andere Weise verteilen, muss diese Daten enthalten, um die richtige Version zu haben. Wenn das Git-Repo diese Informationen enthalten soll, können Sie ausschließen, dass bestimmte Dateien ignoriert werden (dh hinzufügen !*.egg-info/PKG_INFOzu .gitignore).

Zugriff auf die Version über ein Skript

Sie können auf die Metadaten aus dem aktuellen Build in Python-Skripten im Paket selbst zugreifen. Für die Version gibt es zum Beispiel verschiedene Möglichkeiten, dies zu tun, die ich bisher gefunden habe:

## This one is a new built-in as of Python 3.8.0 should become the standard
from importlib-metadata import version

v0 = version("mypackage")
print('v0 {}'.format(v0))

## I don't like this one because the version method is hidden
import pkg_resources  # part of setuptools

v1 = pkg_resources.require("mypackage")[0].version
print('v1 {}'.format(v1))

# Probably best for pre v3.8.0 - the output without .version is just a longer string with
# both the package name, a space, and the version string
import pkg_resources  # part of setuptools

v2 = pkg_resources.get_distribution('mypackage').version
print('v2 {}'.format(v2))

## This one seems to be slower, and with pyinstaller makes the exe a lot bigger
from pbr.version import VersionInfo

v3 = VersionInfo('mypackage').release_string()
print('v3 {}'.format(v3))

Sie können eine davon direkt in Ihr __init__.pyPaket einfügen, um die Versionsinformationen wie folgt zu extrahieren, ähnlich wie bei einigen anderen Antworten:

__all__ = (
    '__version__',
    'my_package_name'
)

import pkg_resources  # part of setuptools

__version__ = pkg_resources.get_distribution("mypackage").version

Nach mehreren Stunden des Versuchs, die einfachste zuverlässige Lösung zu finden, sind hier die Teile:

Erstellen Sie eine version.py-Datei im Ordner Ihres Pakets "/ mypackage":

# Store the version here so:
# 1) we don't load dependencies by storing it in __init__.py
# 2) we can import it in setup.py for the same reason
# 3) we can import it into your module module
__version__ = '1.2.7'

in setup.py:

exec(open('mypackage/version.py').read())
setup(
    name='mypackage',
    version=__version__,

im Hauptordner init .py:

from .version import __version__

Die exec()Funktion führt das Skript außerhalb von Importen aus, da setup.py ausgeführt wird, bevor das Modul importiert werden kann. Sie müssen die Versionsnummer immer noch nur in einer Datei an einem Ort verwalten, aber leider befindet sie sich nicht in setup.py. (Das ist der Nachteil, aber keine Importfehler zu haben, ist der Vorteil)

Seit diese Frage zum ersten Mal gestellt wurde, wurden viele Arbeiten zur einheitlichen Versionierung und zur Unterstützung von Konventionen abgeschlossen . Schmackhafte Optionen werden nun detailliert in der Python Verpackung Benutzerhandbuch . Bemerkenswert ist auch, dass die Versionsnummernschemata in Python gemäß PEP 440 relativ streng sind. Daher ist es wichtig , dass die Dinge gesund bleiben, wenn Ihr Paket im Cheese Shop veröffentlicht wird .

Hier ist eine verkürzte Aufschlüsselung der Versionsoptionen:

1. Lesen Sie die Datei ein setup.py( setuptools ) und erhalten Sie die Version.
2. Verwenden Sie ein externes Build-Tool (um sowohl __init__.pydie Quellcodeverwaltung als auch die Quellcodeverwaltung zu aktualisieren ), z. B. Stoß2version , Änderungen oder zest.releaser .
3. Setzen Sie den Wert __version__in einem bestimmten Modul auf eine globale Variable.
4. Platzieren Sie den Wert in einer einfachen VERSION-Textdatei, damit sowohl setup.py als auch Code gelesen werden können.
5. Legen Sie den Wert über ein setup.pyRelease fest und verwenden Sie importlib.metadata , um ihn zur Laufzeit abzurufen . (Achtung, es gibt Versionen vor 3.8 und nach 3.8.)
6. Setzen Sie den Wert auf __version__in sample/__init__.pyund importieren Sie das Beispiel in setup.py.
7. Verwenden Sie setuptools_scm , um die Versionierung aus der Quellcodeverwaltung zu extrahieren, sodass es sich um die kanonische Referenz und nicht um Code handelt.

HINWEIS : (7) ist möglicherweise der modernste Ansatz (Build-Metadaten sind unabhängig von Code, der durch Automatisierung veröffentlicht wird). Auch HINWEIS dass , wenn Setup für Paket Freigabe verwendet wird , dass ein einfacher python3 setup.py --versiondie Version direkt berichten.

Wenn Sie NumPy distutils verwenden, numpy.distutils.misc_util.Configurationgibt es eine make_svn_version_py()Methode, mit der die Revisionsnummer package.__svn_version__in die Variable eingebettet wird version.

1. Verwenden Sie eine version.pyDatei nur mit __version__ = <VERSION>param in der Datei. In der setup.pyDatei , um den Import __version__param und seinen Wert in der Put - setup.pyDatei wie folgt: version=__version__
2. Eine andere Möglichkeit besteht darin, nur eine setup.pyDatei mit zu verwenden version=<CURRENT_VERSION>- die CURRENT_VERSION ist fest codiert.

Da wir die Version in der Datei nicht jedes Mal manuell ändern möchten, wenn wir ein neues Tag erstellen (bereit, eine neue Paketversion freizugeben), können wir Folgendes verwenden:

Ich kann das Bumpversion- Paket nur empfehlen . Ich benutze es seit Jahren, um eine Version zu stoßen.

Beginnen Sie mit dem Hinzufügen version=<VERSION>zu Ihrer setup.pyDatei, falls Sie diese noch nicht haben.

Sie sollten jedes Mal, wenn Sie eine Version stoßen, ein kurzes Skript wie dieses verwenden:

bumpversion (patch|minor|major) - choose only one option
git push
git push --tags

Dann fügen Sie eine Datei pro Repo genannt: .bumpversion.cfg:

[bumpversion]
current_version = <CURRENT_TAG>
commit = True
tag = True
tag_name = {new_version}
[bumpversion:file:<RELATIVE_PATH_TO_SETUP_FILE>]

Hinweis:

• Sie können __version__Parameter unter version.pyDatei verwenden, wie es in anderen Beiträgen vorgeschlagen wurde, und die Bumpversion-Datei wie folgt aktualisieren: [bumpversion:file:<RELATIVE_PATH_TO_VERSION_FILE>]
• Sie müssen git commit oder git resetalles in Ihrem Repo, sonst erhalten Sie einen schmutzigen Repo-Fehler.
• Stellen Sie sicher, dass Ihre virtuelle Umgebung das Bumpversion-Paket enthält, ohne das es nicht funktioniert.

Wenn Sie CVS (oder RCS) verwenden und eine schnelle Lösung wünschen, können Sie Folgendes verwenden:

__version__ = "$Revision: 1.1 $"[11:-2]
__version_info__ = tuple([int(s) for s in __version__.split(".")])

(Natürlich wird die Revisionsnummer durch CVS ersetzt.)

Auf diese Weise erhalten Sie eine druckfreundliche Version und Versionsinformationen, mit denen Sie überprüfen können, ob das zu importierende Modul mindestens die erwartete Version aufweist:

import my_module
assert my_module.__version_info__ >= (1, 1)