版本范围¶
在上一个部分,我们结束时有几个版本的 pkg 包。让我们删除它们并创建以下简单项目
from conan import ConanFile
class pkgRecipe(ConanFile):
name = "pkg"
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] 方括号引入)
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配方中的requires、tool_requires、test_requires、python_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-Beta 与 1.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.1 比 1.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 版本。 ^1.2.0 的行为相同,而 ^0.1.2 将包含 0.1.2.1 和 0.1.3 版本,但会排除 0.1.1 和 0.2.0。
也可以使用 OR 运算符应用多个条件,例如 requires = "pkg/[>1 <2.0 || ^3.2]",但在实践中不推荐这种复杂的表达式,只应在非常极端的情况下使用。
可以通过字符串末尾的字符串匹配来简化某些范围,否则这些范围需要更复杂的条件(此功能是实验性的)。定义 requires=pkg/[1.2.3.*] 将匹配任何以 1.2.3. 开头的版本,并丢弃其他版本。例如,它将匹配 1.2.3.5 和 1.2.3.abc,但会丢弃 1.2.3(因为它没有最后的点)。
最后,请注意,预发布版本默认不会被解析。包含它们在范围内的办法是使用 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_prerelease 不接收参数,因此无法使用 include_prerelease=False 来禁用预发布版本。
有关有效范围表达式的更多信息,请参阅 Requires 参考