在python包中嵌入版本字符串似乎没有标准的方法。我见过的大多数包都使用您的解决方案的一些变体，即eitner

将版本嵌入到setup.py中，并让setup.py生成一个只包含版本信息的模块(例如version.py)，该模块由你的包导入，或者 相反:把版本信息放在你的包中，然后在setup.py中导入它来设置版本

带有bump2版本的策略路由

这个解决方案来自本文

用例- python GUI包通过PyInstaller分发。需要显示版本信息。

这里是项目包的结构

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包含just

__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]

重写2017 - 05

在写了13年以上的Python代码和管理各种包之后，我得出的结论是，DIY可能不是最好的方法。

我开始使用pbr包来处理包中的版本控制。如果您正在使用git作为您的SCM，这将像魔法一样适合您的工作流，节省您数周的工作时间(您将惊讶于问题的复杂程度)。

截至目前，pbr的月下载量为1200万次，达到这一水平并不需要任何肮脏的手段。这只是一件事——用非常简单的方法解决一个常见的包装问题。

PBR可以承担更多的包维护负担，而且不局限于版本控制，但它不会强迫您采用它的所有好处。

所以为了给你一个关于如何在一次提交中采用策略br的想法，看看切换包装到策略br

您可能会注意到版本根本没有存储在存储库中。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__,
    ...

如果你知道其他更好的方法，请告诉我。

只使用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版本的包，没有它它将无法工作。

不是直接回答你的问题，但你应该考虑将其命名为__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__属性的值应该是一个字符串。