conflict - 运行composer install时如何解决两个包需求冲突？

Question

我想安装这两个包:

“anahkiasen/前任”:“开发大师”

"vespakoen/menu": "dev-master"

但是 composer 说它们每个都依赖于这个包的不同版本:

"anahkiasen/html-object": "dev-master"

"anahkiasen/html-object": "1.1.2"

Problem 1

- Installation request for anahkiasen/former dev-master -> satisfiable by anahkiasen/former[dev-master].
- Can only install one of: anahkiasen/html-object[dev-master, 1.1.2].
- vespakoen/menu dev-master requires anahkiasen/html-object 1.1.2 -> satisfiable by anahkiasen/html-object[1.1.2].
- anahkiasen/former dev-master requires anahkiasen/html-object dev-master -> satisfiable by anahkiasen/html-object[dev-master].
- Installation request for vespakoen/menu dev-master -> satisfiable by vespakoen/menu[dev-master].

我该如何解决？

Answer 1

这里的基本问题是使用分支(dev-master)而不是标记版本。使用分支很可能以问题告终。我正在看 Stackoverflow 上的 Composer 问题，每次有人报告包有问题时，他们 99% 的时间都在使用开发分支和“最小稳定性:开发”。

发生了什么？我必须假设您想第一次安装这些软件包。所以 Composer 不会安装，而是更新包。否则，一组能够满足所有版本要求的工作版本将被记录在 composer.lock 中。 .

所以这里是依赖情况:两个包依赖于第三个包，但这两个需要不兼容的版本。

你能修好它吗？本地只有一个工具composer.json将能够允许安装第三个软件包的文件:使用 inline version alias 安装它.

"require": {
    "anahkiasen/former": "dev-master",
    "vespakoen/menu": "dev-master",
    "anahkiasen/html-object": "dev-master as 1.1.2" /* add this line */
}

通过安装 dev-master 分支并将其声明为 1.1.2 版本，Composer 可以解决两个包的依赖关系。

这样做的问题是，当您拥有三个依赖于第四个包的三个不同版本的包时，它就会失败。

正确的做法是让每个开发分支在 THEIR composer.json 中包含分支别名声明。 ，这将允许 Composer 检测到 dev-master 分支实际上等同于版本 1.1.x，这可能对这里有所帮助(但如果任何包明确要求给定版本号，则不会 - 1.1.x 不是 1.1.2)。添加分支别名仍然是一件好事，应该做。如果维护者想要避免在 composer.json 中不断维护这个硬编码版本别名，他们也可以在名称中带有 .x 版本的分支中开发该版本(即“v1.1.x”或“1.1.x”会被 Composer 检测到包含该版本的开发稳定性)。

请注意，我在最后一段中描述的问题是包明确需要给定的版本号。使用这种方法，如果您需要这样的包，则不能自己或在不同的包中使用该依赖包的不同版本。虽然在某些情况下可能只需要一个版本，但更好的解决方案是需要版本范围。

我个人的偏好是对大于 1.0 的版本使用插入符操作符: ^1.1.7将需要 1.1.7 作为最低版本，但不会更新到任何版本 2.0.0，这被认为具有不兼容的更改。如果一个包根据语义版本控制用新版本仔细标记，这就像一个魅力。您永远不会对不兼容的更改感到惊讶(当然，除非人性干扰，但您应该能够检测到此故障并在软件损坏时回滚更新)。

对于 1.0 以下的版本，请注意插入符运算符的工作方式与波浪号运算符不同 - refer to the manual for more details .我确实更喜欢在我控制下标记为 0.x 的包的波浪号，以便获得“兼容”功能更新，即使语义版本控制允许 0.x 范围内的不兼容更新。

但即使没有语义版本控制，版本号中的每一点不准确都会有所帮助，例如定义 1.1.* (据说将更新到所有即将发布的错误修复版本)或 >=1.1.2,<1.2.5 .

最糟糕的事情是需要“开发大师”。虽然这确实非常不准确(它将解决分支中任何可能的提交，具体取决于您更新的时间)，但问题是除非您确切知道哪个提交，否则您无法返回到“dev-master”的先前版本id 您需要并将此要求添加到 composer.json .但是，您处于与上述完全相同的情况，需要一个确切的版本(git 标签只是提交 ID 的命名别名)。