Как бы то ни было, если вы используете NumPy distutils, numpy.distutils.misc_util.Configuration имеет метод make_svn_version_py(), который вставляет номер версии внутри package.__svn_version__ в переменную version.

Кажется, не существует стандартного способа встроить строку версии в пакет python. Большинство пакетов, которые я видел, используют какой-либо вариант вашего решения, например eitner

1. Вставьте версию в setup.py и попросите setup.py сгенерировать модуль (например, version.py), содержащий только информацию о версии, импортированную вашим пакетом, или

2. Обратное: поместите информацию о версии в сам пакет и импортируйте что, чтобы установить версию в setup.py.

Это не прямой ответ на ваш вопрос, но вам следует подумать о том, чтобы назвать его __version__, а не version.

Это почти квазистандарт. Многие модули в стандартной библиотеке используют __version__, и он также используется в лоты сторонних модулей, так что это квазистандарт.

Обычно __version__ представляет собой строку, но иногда это также число с плавающей запятой или кортеж.

Обновлено: как упоминалось С.Лоттом (спасибо!), PEP 8 прямо говорит об этом:

Module Level Dunder Names

Module level "dunders" (i.e. names with two leading and two trailing underscores) such as __all__, __author__, __version__, etc. should be placed after the module docstring but before any import statements except from __future__ imports.

Вы также должны убедиться, что номер версии соответствует формату, описанному в PEP 440 (PEP 386 предыдущая версия этого стандарта).

Также стоит отметить, что __version__ является полустандартным. в python так и __version_info__, который является кортежем, в простых случаях вы можете просто сделать что-то вроде:

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

... и вы можете получить строку __version__ из файла или что-то еще.

Хотя это, вероятно, слишком поздно, есть немного более простая альтернатива предыдущему ответу:

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

(И было бы довольно просто преобразовать автоматически увеличивающиеся части номеров версий в строку с помощью str().)

Конечно, из того, что я видел, люди склонны использовать что-то вроде ранее упомянутой версии при использовании __version_info__ и, таким образом, хранят ее как кортеж целых чисел; однако я не совсем вижу в этом смысл, так как сомневаюсь, что есть ситуации, когда вы будете выполнять математические операции, такие как сложение и вычитание частей номеров версий, для любых целей, кроме любопытства или автоинкремента (и даже тогда, int() и str() можно использовать довольно легко). (С другой стороны, существует вероятность того, что чей-то другой код ожидает числовой кортеж, а не строковый кортеж, и, следовательно, потерпит неудачу.)

Это, конечно, мое собственное мнение, и я с радостью хотел бы узнать мнение других об использовании числового кортежа.

Как напомнил мне Шези, (лексические) сравнения числовых строк не обязательно дают тот же результат, что и прямые числовые сравнения; Для этого потребуются начальные нули. Таким образом, в конце концов, сохранение __version_info__ (или как бы он там ни назывался) в виде кортежа целочисленных значений позволило бы более эффективно сравнивать версии.

Еще я увидел другой стиль:

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

Я использую один файл _version.py как «некогда каноническое место» для хранения информации о версии:

1. Он предоставляет атрибут __version__.

2. Он предоставляет стандартную версию метаданных. Поэтому он будет обнаружен pkg_resources или другими инструментами, которые анализируют метаданные пакета (EGG-INFO и / или PKG-INFO, PEP 0345).

3. Он не импортирует ваш пакет (или что-либо еще) при сборке вашего пакета, что может вызвать проблемы в некоторых ситуациях. (См. Комментарии ниже о том, какие проблемы это может вызвать.)

4. Номер версии записан только в одном месте, поэтому есть только одно место для его изменения при изменении номера версии, и вероятность несовместимости версий меньше.

Вот как это работает: «единственное каноническое место» для хранения номера версии - это файл .py с именем «_version.py», который находится в вашем пакете Python, например, в myniftyapp/_version.py. Этот файл является модулем Python, но ваш setup.py не импортирует его! (Это приведет к поражению функции 3.) Вместо этого ваш setup.py знает, что содержимое этого файла очень простое, что-то вроде:

__version__ = "3.6.5"

Итак, ваш setup.py открывает файл и анализирует его с таким кодом, как:

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,))

Затем ваш setup.py передает эту строку в качестве значения аргумента "версия" в setup(), таким образом удовлетворяя функцию 2.

Чтобы удовлетворить функцию 1, вы можете заставить свой пакет (во время выполнения, а не во время установки!) Импортировать файл _version из myniftyapp/__init__.py следующим образом:

from _version import __version__

Вот пример этой техники, который я использую годами.

Код в этом примере немного сложнее, но упрощенный пример, который я написал в этом комментарии, должен быть полной реализацией.

Вот пример кода импорта версии.

Если вы видите что-то неправильное в этом подходе, дайте мне знать.

Для отложенного PEP 396 (номера версий модулей) есть предлагаемый способ сделать это. Он описывает с обоснованием (по общему признанию, необязательный) стандарт, которому должны следовать модули. Вот отрывок:

3) When a module (or package) includes a version number, the version SHOULD be available in the __version__ attribute.

4) For modules which live inside a namespace package, the module SHOULD include the __version__ attribute. The namespace package itself SHOULD NOT include its own __version__ attribute.

5) The __version__ attribute's value SHOULD be a string.

Переписано 2017-05

После 13 с лишним лет написания кода Python и управления различными пакетами я пришел к выводу, что DIY, возможно, не лучший подход.

Я начал использовать пакет pbr для управления версиями в моих пакетах. Если вы используете git в качестве SCM, это впишется в ваш рабочий процесс как по волшебству, сэкономив вам недели работы (вы будете удивлены, насколько сложной может быть проблема).

На сегодняшний день pbr - 11-й по популярности пакет Python, и достижение этого уровня не предполагало никаких подвохов. Было только одно - решить обычную проблему с упаковкой очень простым способом.

pbr может облегчить бремя обслуживания пакетов и не ограничивается управлением версиями, но не заставляет вас использовать все его преимущества.

Итак, чтобы дать вам представление о том, как выглядит принятие pbr за один коммит, взгляните на переключение упаковки на pbr

Возможно, вы заметили, что версия вообще не хранится в репозитории. PBR обнаруживает его по веткам и тегам Git.

Не нужно беспокоиться о том, что происходит, когда у вас нет репозитория git, потому что pbr «компилирует» и кеширует версию, когда вы упаковываете или устанавливаете приложения, поэтому нет зависимости от git во время выполнения.

Старое решение

Вот лучшее решение, которое я видел до сих пор, и оно также объясняет, почему:

Внутри 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'

Внутри yourpackage/__init__.py:

from .version import __version__

Внутри setup.py:

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

Если вы знаете другой подход, который кажется лучше, дайте мне знать.

Я использую файл JSON в каталоге пакета. Это соответствует требованиям Zooko.

Внутри pkg_dir/pkg_info.json:

{"version": "0.1.0"}

Внутри 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'],
    ...
    )

Внутри 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']

Я также поместил другую информацию в pkg_info.json, как и автор. я Мне нравится использовать JSON, потому что я могу автоматизировать управление метаданными.

стрела справляется с этим интересным образом.

Сейчас (с 2e5031b)

В arrow/__init__.py:

__version__ = 'x.y.z'

В setup.py:

from arrow import __version__

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

Перед

В arrow/__init__.py:

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

В 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__'),
    # [...]
)

Если вы используете CVS (или RCS) и хотите получить быстрое решение, вы можете использовать:

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

(Конечно, номер версии будет заменен вам CVS.)

Это дает вам версию для печати и информацию о версии, которую вы можете использовать, чтобы проверить, что модуль, который вы импортируете, имеет по крайней мере ожидаемую версию:

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

Многие из этих решений здесь игнорируют теги версий git, что по-прежнему означает, что вам нужно отслеживать версию в нескольких местах (плохо). Я подошел к этому со следующими целями:

• Извлечь все ссылки на версии Python из тега в репозитории git
• Автоматизируйте шаги git tag / push и setup.py upload с помощью одной команды, которая не требует ввода.

Как это работает:

1. С помощью команды make release будет найдена и увеличена последняя версия с тегами в репозитории git. Тег возвращается в origin.

2. Makefile хранит версию в src/_version.py, где она будет прочитана setup.py и также включена в релиз. Не проверяйте _version.py в системе контроля версий!

3. Команда setup.py считывает строку новой версии из package.__version__.

Подробности:

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

Цель release всегда увеличивает 3-ю цифру версии, но вы можете использовать next_minor_ver или next_major_ver для увеличения других цифр. Команды полагаются на сценарий versionbump.py, который проверяется в корне репо.

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

Это делает тяжелую работу по обработке и увеличению номера версии из git.

__init__.py

Файл my_module/_version.py импортируется в my_module/__init__.py. Поместите сюда любую статическую конфигурацию установки, которую вы хотите распространить с вашим модулем.

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

setup.py

Последний шаг - прочитать информацию о версии из модуля my_module.

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__'],
    ...
    ...
)

Конечно, для того, чтобы все это работало, вам нужно иметь хотя бы один тег версии в вашем репо для запуска.

git tag -a v0.0.1

1. Используйте файл version.py только с параметром __version__ = <VERSION> в файле. В файле setup.py импортируйте параметр __version__ и поместите его значение в файл setup.py следующим образом: version=__version__
2. Другой способ - использовать только файл setup.py с version=<CURRENT_VERSION> - CURRENT_VERSION жестко запрограммирована.

Поскольку мы не хотим вручную изменять версию в файле каждый раз, когда мы создаем новый тег (готовый к выпуску новой версии пакета), мы можем использовать следующее:

Я очень рекомендую пакет bumpversion. Я уже много лет использую его, чтобы поднять версию.

начните с добавления version=<VERSION> в ваш файл setup.py, если у вас его еще нет.

Вы должны использовать такой короткий скрипт каждый раз, когда поднимаете версию:

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

Затем добавьте по одному файлу для каждого репо: .bumpversion.cfg:

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

Примечание:

• Вы можете использовать параметр __version__ в файле version.py, как это предлагалось в других сообщениях, и обновить файл bumpversion следующим образом: [bumpversion:file:<RELATIVE_PATH_TO_VERSION_FILE>]
• Вы долженgit commit или git reset все в своем репо, иначе вы получите грязную ошибку репо.
• Убедитесь, что ваша виртуальная среда включает пакет bumpversion, без него он работать не будет.

Использование setuptools и pbr

Не существует стандартного способа управления версией, но стандартным способом управления вашими пакетами является setuptools.

Лучшее решение, которое я нашел в целом для управления версией, - это использовать setuptools с расширением pbr. Теперь это мой стандартный способ управления версиями.

Настройка вашего проекта для полной упаковки может быть излишней для простых проектов, но если вам нужно управлять версией, вы, вероятно, находитесь на правильном уровне, чтобы просто все настроить. Это также делает ваш пакет доступным для выпуска по адресу PyPi, так что каждый может загрузить и использовать его с Pip.

PBR перемещает большую часть метаданных из инструментов setup.py в файл setup.cfg, который затем используется в качестве источника для большинства метаданных, которые могут включать версию. Это позволяет упаковать метаданные в исполняемый файл, используя что-то вроде pyinstaller, если это необходимо (если это так, вы, вероятно, будете использовать нужна эта информация), и отделяет метаданные от других сценариев управления / настройки пакетов. Вы можете напрямую обновить строку версии в setup.cfg вручную, и она будет помещена в папку *.egg-info при сборке выпусков вашего пакета. Затем ваши сценарии могут получить доступ к версии из метаданных с помощью различных методов (эти процессы описаны в разделах ниже).

При использовании Git для VCS / SCM эта настройка даже лучше, поскольку она будет извлекать много метаданных из Git, так что ваше репо может быть вашим основным источником правды для некоторых метаданных, включая версию, авторов, журналы изменений, и т. д. В частности, для версии он создаст строку версии для текущего коммита на основе тегов git в репозитории.

• PyPA - Упаковка пакетов Python с помощью SetupTools - Учебное пособие
• Документация по использованию последней сборки PBR - Как настроить 8-строчный файл setup.py и файл setup.cfg с метаданными.

Поскольку PBR будет извлекать версию, автора, журнал изменений и другую информацию непосредственно из вашего репозитория git, некоторые метаданные в setup.cfg могут быть исключены и автоматически сгенерированы всякий раз, когда для вашего пакета создается дистрибутив (с использованием setup.py).

Получите актуальную версию в режиме реального времени

setuptools будет получать самую свежую информацию в режиме реального времени с помощью setup.py:

python setup.py --version

Это приведет к получению последней версии либо из файла setup.cfg, либо из репозитория git на основе последней сделанной фиксации и тегов, существующих в репо. Однако эта команда не обновляет версию в дистрибутиве.

Обновление метаданных версии

Когда вы создаете дистрибутив с setup.py (например, py setup.py sdist), вся текущая информация будет извлечена и сохранена в дистрибутиве. По сути, это запускает команду setup.py --version, а затем сохраняет эту информацию о версии в папке package.egg-info в наборе файлов, в которых хранятся метаданные распространения.

Note on process to update version meta-data:

If you are not using pbr to pull version data from git, then just update your setup.cfg directly with new version info (easy enough, but make sure this is a standard part of your release process).

If you are using git, and you don't need to create a source or binary distribution (using python setup.py sdist or one of the python setup.py bdist_xxx commands) the simplest way to update the git repo info into your <mypackage>.egg-info metadata folder is to just run the python setup.py install command. This will run all the PBR functions related to pulling metadata from the git repo and update your local .egg-info folder, install script executables for any entry-points you have defined, and other functions you can see from the output when you run this command.

Note that the .egg-info folder is generally excluded from being stored in the git repo itself in standard Python .gitignore files (such as from Gitignore.IO), as it can be generated from your source. If it is excluded, make sure you have a standard "release process" to get the metadata updated locally before release, and any package you upload to PyPi.org or otherwise distribute must include this data to have the correct version. If you want the Git repo to contain this info, you can exclude specific files from being ignored (i.e. add !*.egg-info/PKG_INFO to .gitignore)

Доступ к версии из скрипта

Вы можете получить доступ к метаданным из текущей сборки в скриптах Python в самом пакете. Для версии, например, я нашел несколько способов сделать это:

## 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))

Вы можете поместить один из них прямо в свой __init__.py, чтобы пакет извлек информацию о версии следующим образом, как и в некоторых других ответах:

__all__ = (
    '__version__',
    'my_package_name'
)

import pkg_resources  # part of setuptools

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

После нескольких часов попыток найти самое простое и надежное решение, вот детали:

создайте файл version.py ВНУТРИ папки вашего пакета "/ 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'

в setup.py:

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

в основной папке в этом.py:

from .version import __version__

Функция exec() запускает сценарий вне любого импорта, поскольку setup.py запускается до того, как модуль может быть импортирован. Вам по-прежнему нужно управлять номером версии в одном файле в одном месте, но, к сожалению, этого нет в setup.py. (это недостаток, но отсутствие ошибок импорта - положительный момент)

Была завершена большая работа по единообразному управлению версиями и в поддержку соглашений так как этот вопрос был впервые задан. Приятные варианты теперь подробный в Руководство пользователя Python Packaging. Также стоит отметить, что схемы номеров версий относительно строги в Python в соответствии с PEP 440, и поэтому сохранение рассудка имеет решающее значение, если ваш пакет будет выпущен в Сырная лавка.

Вот сокращенная разбивка вариантов управления версиями:

1. Прочтите файл в setup.py (setuptools) и получите версию.
2. Используйте внешний инструмент сборки (для обновления как __init__.py, так и системы управления версиями), например bump2version, изменения или zest.releaser.
3. Установите значение глобальной переменной __version__ в конкретном модуле.
4. Поместите значение в простой текстовый файл VERSION для чтения и setup.py, и кода.
5. Установите значение через выпуск setup.py и используйте importlib.metadata, чтобы поднять его во время выполнения. (Внимание! Существуют версии до 3.8 и после 3.8.)
6. Установите значение __version__ в sample/__init__.py и импортируйте семпл в setup.py.
7. Используйте setuptools_scm для извлечения управления версиями из системы управления версиями, чтобы это была каноническая ссылка, а не код.

ПРИМЕЧАНИЕ, который (7) может быть самый современный подход (метаданные сборки не зависят от кода, опубликованного автоматизацией). Также ПРИМЕЧАНИЕ, что если установка используется для выпуска пакета, простой python3 setup.py --version сообщит версию напрямую.

Я предпочитаю читать версию пакета из среды установки. Это мой src/foo/_version.py:

from pkg_resources import get_distribution                                        
                                                                                  
__version__ = get_distribution('osbc').version

Убедитесь, что foo всегда уже установлен, поэтому требуется слой src/ для предотвращения импорта foo без установки.

В setup.py я использую setuptools-scm для автоматического создания версии.

pbr с bump2version

Это решение было получено из эта статья

Вариант использования - пакет графического интерфейса Python, распространяемый через PyInstaller. Требуется показать информацию о версии.

Вот структура проекта packagex

packagex
├── packagex
│   ├── __init__.py
│   ├── main.py
│   └── _version.py
├── packagex.spec
├── LICENSE
├── README.md
├── .bumpversion.cfg
├── requirements.txt
├── setup.cfg
└── setup.py

где setup.py - это

# setup.py
import os

import setuptools

about = {}
with open("packagex/_version.py") as f:
    exec(f.read(), about)

os.environ["PBR_VERSION"] = about["__version__"]

setuptools.setup(
    setup_requires=["pbr"],
    pbr=True,
    version=about["__version__"],
)

packagex/_version.py содержит только

__version__ = "0.0.1"

и packagex/__init__.py

from ._version import __version__

и для .bumpversion.cfg

[bumpversion]
current_version = 0.0.1
commit = False
tag = False
parse = (?P<major>\d+)\.(?P<minor>\d+)\.(?P<patch>\d+)(\-(?P<release>[a-z]+)(?P<build>\d+))?
serialize = 
    {major}.{minor}.{patch}-{release}{build}
    {major}.{minor}.{patch}

[bumpversion:part:release]
optional_value = prod
first_value = dev
values = 
    dev
    prod

[bumpversion:file:packagex/_version.py]

1. Создайте файл с именем _version.txt в той же папке, что и __init__.py, и запишите версию в виде одной строки:

0.8.2

2. Прочтите эту информацию из файла _version.txt в __init__.py:

    import os 
    def get_version():
        with open(os.path.join(os.path.abspath(os.path.dirname(__file__)), "_version.txt")) as f:
            return f.read().strip() 
    __version__ = get_version()