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

Question

我想安装这两个包:

• "anahkiasen/former":"dev-master"
• "vespakoen/menu":"dev-master"

但作曲家说,他们每个人都依赖于这个包的不同版本:

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

问题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%的时间内使用开发分支和"minimum-stability:dev".

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

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

你能修好它吗？本地composer.json文件中只有一个工具可以允许安装第三个包:使用内联版本别名安装它.

"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,这可能对此有帮助(但如果有的话) package明确要求给定版本号--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以下的版本,请注意插入符号操作符与波形符操作符不同 - 有关详细信息,请参阅手册.我更喜欢使用标签0.x控制我的标签下的软件包,以便获得"兼容"功能更新,即使语义版本控制允许在0.x范围内进行不兼容的更新.

但即使没有语义版本控制,版本号中的每一点不准确都会有所帮助,比如定义1.1.*(据说将更新到所有即将推出的bugfix版本)或>=1.1.2,<1.2.5.

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