使用setuptools和pyproject.toml

Setuptools现在提供了一种动态获取pyproject.toml版本的方法

重现这里的示例，您可以在pyproject.toml中创建如下内容

# ...
[project]
name = "my_package"
dynamic = ["version"]
# ...
[tool.setuptools.dynamic]
version = {attr = "my_package.__version__"}

只使用VERSION .py文件，文件中有__version__ = <VERSION>参数。在setup.py文件中导入__version__参数，并将其值放在setup.py文件中，如下所示: version = __version__ 另一种方法是只使用version=<CURRENT_VERSION>的setup.py文件- CURRENT_VERSION是硬编码的。

因为我们不希望每次创建一个新标记(准备发布一个新的包版本)时都手动更改文件中的版本，所以我们可以使用以下..

我强烈推荐凸版包。多年来我一直在用它来撞一个版本。

首先在setup.py文件中添加version=< version >，如果你还没有的话。

你应该在每次碰到一个版本时使用这样一个简短的脚本:

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

然后为每个repo添加一个名为.bumpversion.cfg的文件:

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

注意:

你可以像在其他文章中建议的那样，在version.py文件下使用__version__参数，并像这样更新bumpversion文件: [bumpversion:文件:< RELATIVE_PATH_TO_VERSION_FILE >) 你必须git提交或git重置你的回购中的所有东西，否则你会得到一个肮脏的回购错误。 确保你的虚拟环境包含了bump版本的包，没有它它将无法工作。

自从第一次提出这个问题以来，已经完成了许多关于统一版本和支持约定的工作。可接受的选项现在在Python打包用户指南中详细介绍。同样值得注意的是，版本号方案在Python PEP 440中是相对严格的，因此如果您的包将被发布到Cheese Shop，那么保持正常是至关重要的。

以下是版本控制选项的简短分类:

Read the file in setup.py (setuptools) and get the version. Use an external build tool (to update both __init__.py as well as source control), e.g. bump2version, changes or zest.releaser. Set the value to a __version__ global variable in a specific module. Place the value in a simple VERSION text file for both setup.py and code to read. Set the value via a setup.py release, and use importlib.metadata to pick it up at runtime. (Warning, there are pre-3.8 and post-3.8 versions.) Set the value to __version__ in sample/__init__.py and import sample in setup.py. Use setuptools_scm to extract versioning from source control so that it's the canonical reference, not code.

注意(7)可能是最现代的方法(构建元数据独立于代码，由自动化发布)。还要注意，如果setup用于包发布，那么简单的python3 setup.py——version将直接报告版本。

不是直接回答你的问题，但你应该考虑将其命名为__version__，而不是version。

这几乎是一个准标准。标准库中的许多模块使用__version__，这也在许多第三方模块中使用，因此它是准标准的。

通常，__version__是一个字符串，但有时它也是一个浮点数或元组。

正如S.Lott所提到的(谢谢!)，PEP 8明确表示:

模块级别Dunder名称 模块级别的“dunders”(即名称有两个前导和两个后导 下划线)，例如__all__， __author__， __version__等。 应该放在模块文档字符串之后，但在任何导入之前 除了__future__导入之外的语句。

您还应该确保版本号符合PEP 440 (PEP 386是此标准的以前版本)中描述的格式。

根据延迟的[STOP PRESS: rejected] PEP 396(模块版本号)，有一种建议的方法来做到这一点。它描述了模块遵循的基本原理(当然是可选的)标准。下面是一个片段:

当模块(或包)包含版本号时，该版本应该在__version__属性中可用。

对于位于命名空间包中的模块，模块应该包含__version__属性。命名空间包本身不应该包含自己的__version__属性。

__version__属性的值应该是一个字符串。

《绿箭侠》以一种有趣的方式处理它。

现在(2e5031b起)

在箭头/ __init__ . py:

__version__ = 'x.y.z'

在setup . py:

from arrow import __version__

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

之前

在箭头/ __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__'),
    # [...]
)