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文件中只有一个工具可以允许安装第三个包：使用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的软件包，以便获得“兼容”功能更新，即使语义版本控制允许在0.x范围内进行不兼容的更新。

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

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

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

1 个答案: