依赖冲突¶
在依赖图中,当不同的包依赖于同一包的不同版本时,这被称为依赖版本冲突。产生一个冲突相对容易。让我们通过一个实际的例子来了解一下,首先克隆 examples2 仓库
$ git clone https://github.com/conan-io/examples2.git
$ cd examples2/tutorial/versioning/conflicts/versions
在这个文件夹中,我们有一个小项目,由几个包组成:matrix(一个数学库),engine/1.0 视频游戏引擎,它依赖于 matrix/1.0,intro/1.0,一个实现游戏片头和功能的包,它依赖于 matrix/1.1,最后是 game 配方,它同时依赖于 engine/1.0 和 intro/1.0。所有这些包实际上都是空的,但它们足以产生冲突。
让我们创建依赖项
$ conan create matrix --version=1.0
$ conan create matrix --version=1.1 # note this is 1.1!
$ conan create engine --version=1.0 # depends on matrix/1.0
$ conan create intro --version=1.0 # depends on matrix/1.1
当我们尝试安装 game 时,我们会得到错误
$ conan install game
Requirements
engine/1.0#0fe4e6890766f7b8e21f764f0049aec7 - Cache
intro/1.0#d639998c2e55cf36d261ab319801c322 - Cache
matrix/1.0#905c3f0babc520684c84127378fefdd0 - Cache
Graph error
Version conflict: intro/1.0->matrix/1.1, game/1.0->matrix/1.0.
ERROR: Version conflict: intro/1.0->matrix/1.1, game/1.0->matrix/1.0.
这是一个版本冲突,Conan 不会自动决定如何解决冲突,而是应该由用户显式地解决此类冲突。
解决冲突¶
当然,解决此类冲突的最直接和最简单的方法是转到依赖项的 conanfile.py 并升级它们的 requirements(),以便它们现在指向相同的版本。但是,在某些情况下,这可能不切实际,或者可能无法修复依赖项的 conanfile。
在这种情况下,应该由消费的 conanfile.py(在本例中为 game)来解决冲突,通过显式定义应使用依赖项的哪个版本,使用以下语法
class Game(ConanFile):
name = "game"
version = "1.0"
def requirements(self):
self.requires("engine/1.0")
self.requires("intro/1.0")
self.requires("matrix/1.1", override=True)
这称为 override。 game 包不直接依赖于 matrix,此 requires 声明不会引入这样的直接依赖关系。但是 matrix/1.1 版本将在上游依赖图中传播,覆盖依赖于任何 matrix 版本的包的 requires,从而强制依赖图的一致性,因为所有上游包现在都将依赖于 matrix/1.1
$ conan install game
...
Requirements
engine/1.0#0fe4e6890766f7b8e21f764f0049aec7 - Cache
intro/1.0#d639998c2e55cf36d261ab319801c322 - Cache
matrix/1.1#905c3f0babc520684c84127378fefdd0 - Cache
注意
在这种情况下,不需要为 engine/1.0 创建新的二进制文件,但在某些情况下,上述操作可能会因 engine/1.0 “二进制文件丢失错误”而失败。因为之前 engine/1.0 二进制文件是针对 matrix/1.0 构建的。如果 package_id 规则和配置定义了当依赖项的次要版本发生变化时,应该重建 engine,那么就需要构建一个新的 engine/1.0 二进制文件,该文件构建并链接到新的 matrix/1.1 依赖项。
如果 game 对 matrix/1.2 有直接依赖关系会怎样?让我们创建版本
$ conan create matrix --version=1.2
现在让我们修改 game/conanfile.py 以引入此作为直接依赖项
class Game(ConanFile):
name = "game"
version = "1.0"
def requirements(self):
self.requires("engine/1.0")
self.requires("intro/1.0")
self.requires("matrix/1.2")
所以安装它会再次引发冲突错误
$ conan install game
...
ERROR: Version conflict: engine/1.0->matrix/1.0, game/1.0->matrix/1.2.
由于这次,我们希望尊重 game 和 matrix 之间的直接依赖关系,我们将定义 force=True 需求特征,以指示此依赖项版本也将强制上游覆盖
class Game(ConanFile):
name = "game"
version = "1.0"
def requirements(self):
self.requires("engine/1.0")
self.requires("intro/1.0")
self.requires("matrix/1.2", force=True)
这将再次解决冲突(如上所述,请注意,在实际应用中,这可能意味着 engine/1.0 和 intro/1.0 的二进制文件可能丢失,需要构建以链接到新的强制 matrix/1.2 版本)
$ conan install game
Requirements
engine/1.0#0fe4e6890766f7b8e21f764f0049aec7 - Cache
intro/1.0#d639998c2e55cf36d261ab319801c322 - Cache
matrix/1.2#905c3f0babc520684c84127378fefdd0 - Cache
注意
最佳实践
通常,通过覆盖/强制解决版本冲突应该是一种例外,并在可能时避免,作为临时解决方法。真正的解决方案是推进依赖项的
requires,以便它们自然地收敛到上游依赖项的相同版本。一个关键的收获是,
force特征将在消费者和所需的包之间创建直接依赖关系,而override不会,它只会指示 Conan 优先选择依赖图中已存在的包的版本。版本范围也可能产生一些版本冲突,即使 Conan 试图减少它们。此 关于版本冲突的常见问题解答 讨论了图解析算法以及最大限度地减少冲突的策略。
覆盖选项¶
当依赖图中存在像上面看到的那样的菱形结构时,不同的配方可能会为上游 options 定义不同的值。在这种情况下,这不会直接导致冲突,而是首先定义的值将是优先选择并生效的值。
在上面的例子中,如果 matrix/1.0 既可以是静态库也可以是共享库,并且 engine 决定定义它应该是静态库(实际上不需要,因为这已经是默认值)
class Engine(ConanFile):
name = "engine"
version = "1.0"
# Not strictly necessary because this is already the matrix default
default_options = {"matrix*:shared": False}
警告
在配方中定义选项值没有强烈的保证,请查看 关于依赖项选项值的常见问题解答。定义选项值的推荐方法是在配置文件中。
并且 intro 配方也会这样做,但相反地定义它想要一个共享库,并添加一个 validate() 方法,因为出于某种原因,intro 包只能针对共享库构建,否则会崩溃
class Intro(ConanFile):
name = "intro"
version = "1.0"
default_options = {"matrix*:shared": True}
def requirements(self):
self.requires("matrix/1.0")
def validate(self):
if not self.dependencies["matrix"].options.shared:
raise ConanInvalidConfiguration("Intro package doesn't work with static matrix library")
然后,这将导致错误,因为首先定义选项值的是 engine(它在 game conanfile 的 requirements() 方法中首先声明)。在 examples2 仓库中,转到“options”文件夹,并创建不同的包
$ cd ../options
$ conan create matrix
$ conan create matrix -o matrix/*:shared=True
$ conan create engine
$ conan create intro
$ conan install game # FAILS!
...
-------- Installing (downloading, building) binaries... --------
ERROR: There are invalid packages (packages that cannot exist for this configuration):
intro/1.0: Invalid: Intro package doesn't work with static matrix library
遵循相同的原则,下游消费者配方,在本例中为 game conanfile.py 可以定义选项值,并且这些值将具有优先权
class Game(ConanFile):
name = "game"
version = "1.0"
default_options = {"matrix*:shared": True}
def requirements(self):
self.requires("engine/1.0")
self.requires("intro/1.0")
这将强制 matrix 成为共享库,无论 engine 定义 shared=False,因为下游消费者始终优先于上游依赖项。
$ conan install game
...
-------- Installing (downloading, building) binaries... --------
matrix/1.0: Already installed!
matrix/1.0: I am a shared-library library!!!
engine/1.0: Already installed!
intro/1.0: Already installed!
注意
最佳实践
作为一般规则,避免在消费者的 conanfile.py 中修改或定义依赖项的 options 值。声明的 options 默认值应该适用于大多数情况,并且对这些默认值的变化可以更好地在配置文件中定义。