版本范围

在上一节中,我们以 pkg 包的几个版本结束。让我们删除它们并创建以下简单的项目

pkg/conanfile.py
from conan import ConanFile

class pkgRecipe(ConanFile):
    name = "pkg"
app/conanfile.py
from conan import ConanFile

class appRecipe(ConanFile):
    name = "app"
    requires = "pkg/1.0"

让我们创建 pkg/1.0 并安装 app,以查看它需要 pkg/1.0

$ conan remove "pkg*" -c
$ conan create pkg --version=1.0
... pkg/1.0 ...
$ conan install app
...
Requirements
    pkg/1.0

然后,如果我们创建 pkg 的新版本 1.1,它不会自动被 app 使用

$ conan create pkg --version=1.1
... pkg/1.0 ...
# Note how this still uses the previous 1.0 version
$ conan install app
...
Requirements
    pkg/1.0

因此,我们可以修改 app 的 conanfile 以显式使用新的 pkg/1.1 版本,但与其这样做,不如使用以下版本范围表达式(由 [expression] 括号引入)

app/conanfile.py
from conan import ConanFile

class appRecipe(ConanFile):
    name = "app"
    requires = "pkg/[>=1.0 <2.0]"

当我们现在安装 app 的依赖项时,它会自动使用范围内的最新版本,即使我们创建了一个新版本,也不需要修改 app 的 conanfile

# this will now use the newer 1.1
$ conan install app
...
Requirements
    pkg/1.1

$ conan create pkg --version=1.2
... pkg/1.2 ...
# Now it will automatically use the newest 1.2
$ conan install app
...
Requirements
    pkg/1.2

只要较新版本位于定义的范围内,这就会一直有效,如果我们创建 pkg/2.0 版本,app 不会使用它

$ conan create pkg --version=2.0
... pkg/2.0 ...
# Conan will use the latest in the range
$ conan install app
...
Requirements
    pkg/1.2

使用版本范围时,缓存中的版本优先于远程版本,因此如果您有本地 pkg/1.2 包,它将被使用而不是远程版本,即使远程版本更新。要确保使用最新的可用版本,您可以在 install/create 命令中使用 --update 参数。请注意,--update 参数将查看命令中指定的所以远程仓库中是否有更新的版本,并且不会在找到第一个更新的版本后停止。

版本范围可以在多个地方定义

  • conanfile.py 食谱的 requirestool_requirestest_requirespython_requires

  • conanfile.txt 文件的 [requires][tool_requires][test_requires] 部分中

  • 在命令行参数中,如 --requires=--tool_requires

  • 在配置文件的 [tool_requires] 部分中

语义化版本控制

语义化版本控制规范或 semver 指定包应始终使用 3 个点分隔的数字进行版本控制,如 MAJOR.MINOR.PATCH,每个数字都有非常具体的含义。

Conan 将 semver 规范扩展到任意数量的数字,并且还允许在其中包含小写字母。之所以这样做,是因为在 1.X 期间,收集了大量来自用户的经验和反馈,并且很明显,在 C++ 中,版本控制方案通常更复杂,用户需要更大的灵活性,允许版本如 1.2.3.a.8(如有必要)。

Conan 版本的非数字标识符遵循与包名称相同的规则,它们只能包含小写字母。这样做是为了避免 1.2.3-Beta1.2.3-beta 成为不同的版本,这可能会造成问题,甚至存在安全风险。

必要时版本的排序(例如,确定版本范围内哪个是最新的版本)是通过从左到右逐个比较版本中每个点分隔的实体来完成的。数字将按数值进行比较,因此 2 < 11,包含字母的条目将按字母顺序进行比较(即使它们也包含一些数字)。

与 semver 规范类似,Conan 可以管理 预发布版构建版本,形式为:VERSION-prerelease+build。Conan 还将根据相同的规则对预发布版和构建版本进行排序,并且每个版本也可以包含任意数量的项目,例如 1.2.3-pre.1.2.1+build.45.a。请注意,semver 标准不对构建版本应用任何排序规则,但 Conan 会应用,并且逻辑与用于排序主版本和预发布版的逻辑相同。

重要

请注意,预发布版的排序有时可能会令人困惑。预发布版在时间上早于它限定的发布版。因此 1.1-alpha.11.1 旧,而不是更新。

范围表达式

范围表达式可以对上下限使用比较运算符,并用空格分隔。此外,允许单独使用下限和上限,尽管在正常的版本控制方案下,通常不建议这样做,尤其是仅使用下限。 requires = "pkg/[>=1.0 <2.0]" 将包含 1.0、1.2.3 和 1.9 等版本,但不包括 0.3、2.0 或 2.1 版本。

波浪号 ~ 运算符可用于定义“大约”相等的版本范围。 requires = "pkg/[~1]" 将包含版本 1.3 和 1.8.1,但不包括版本 0.8 或 2.0。同样,requires = "pkg/[~2.5]" 将包含 2.5.0 和 2.5.3,但不包括 2.1、2.7、2.8。

插入符号 ^ 运算符与波浪号非常相似,但允许最后定义的数字发生变化。 requires = "pkg/[^1.2]" 将包含 1.2.1、1.3 和 1.51,但不包括 1.0、2、2.0。

也可以使用 OR 运算符应用多个条件,例如 requires = "pkg/[>1 <2.0 || ^3.2]",但这种复杂的表达式在实践中不建议使用,仅应在极端情况下使用。

最后,请注意,默认情况下不会解析预发布版。将其包含在范围内的办法是使用 include_prerelease 选项(requires = "pkg/[>1 <2, include_prerelease]")或通过 core.version_ranges:resolve_prereleases=True 配置显式启用它们。在此示例中,将包含 1.0-pre.1 和 1.5.1-pre1,但将排除 2.0-pre1。

注意

虽然可以在 requires 版本范围内硬编码 include_prerelease,但通常不建议这样做。预发布版应该是选择加入的,并由用户控制,用户决定是否要使用预发布版。此外,请注意,include_prereleases 不接收任何参数,因此无法使用 include_prerelease=False 禁用预发布版。

有关有效范围表达式的更多信息,请转到 Requires 参考