运行composer install时如何解决两个包需求冲突? [英] How to solve two packages requirements conflicts when running composer install?

问题描述

我要安装这两个包:

• anahkiasen/former":开发大师"
• "vespakoen/menu": "dev-master"

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

But composer says that each of them depends on diferent versions of this package:

• "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].

我该如何解决?

推荐答案

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

The basic problem here is the use of branches (dev-master) instead of tagged versions. Using branches is very likely to end in problems. I am watching the Composer questions on Stackoverflow, and every time someone reports trouble with packages, they are using development branches and "minimum-stability:dev" 99% of the time.

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

What's happening? I must assume that you want to install these packages for the first time. So Composer does not install, but update the packages. Otherwise a working set of versions that are able to fulfill all version requirements would have been recorded in the composer.lock.

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

So here is the dependency situation: Two packages depend on a third package, but these two require incompatible versions.

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

Can you fix it? There is only one tool in the local composer.json file that will be able to allow installing the third package: Installing it with an 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 可以解决两个包的依赖关系.

By installing the dev-master branch and declare it to be like version 1.1.2, Composer can resolve the dependencies of both packages.

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

The problem with this is that it will fail the very moment you have three packages depending on a fourth - in three different versions.

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

The correct thing would be for every development branch to include a branch-alias declaration in THEIR composer.json, which will allow Composer to detect that the dev-master branch actually is equivalent to version 1.1.x, which might have helped here (but not if any package explicitly requires a given version number - 1.1.x is not 1.1.2). Adding branch aliases still is a good thing and should be done. If a maintainer wants to avoid the constant maintenance of this hardcoded version alias in composer.json, they can alternatively develop that version in a branch that bears that .x version in their name (i.e. "v1.1.x" or "1.1.x" would be detected by Composer to contain said version in development stability).

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

Note that the problem I described in the last paragraph is that packages explicitly require a given version number. With this approach, if you require such a package, you cannot use an different version of that depended package yourself or in a different package. While there might be cases for requiring only one version, the better solution is to require version ranges.

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

My personal preference is to use the caret operator for versions greater than 1.0: ^1.1.7 would require 1.1.7 as the minimum version, but would not update to any version 2.0.0, which is considered having incompatible changes. If a package is carefully tagged with new version according to semantic versioning, this works like a charm. You'd never be surprised by incompatible changes (unless of course human nature interferes, but you should be able to detect this failure and roll back the update if your software breaks).

对于 1.0 以下的版本，请注意插入符运算符与波浪号运算符的工作方式不同 - 参考手册了解更多详情.即使语义版本控制允许 0.x 范围内的不兼容更新，我也更喜欢在我控制下标记为 0.x 的包以获取兼容"功能更新.

For versions below 1.0, note that the caret operator works different from the tilde operator - refer to the manual for more details. I do prefer tilde for packages under my control that were tagged 0.x in order to get "compatible" feature updates even if semantic versioning allows incompatible updates in the 0.x range.

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

But even without semantic versioning, every little bit of inaccuracy in the version number helps, like defining 1.1.* (supposedly will update to all upcoming bugfix releases) or >=1.1.2,<1.2.5.

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

The worst things of all is requiring "dev-master". While this is indeed very inaccurate (it will resolve to any possible commit in the branch, depending on the time you update), the problem is that you cannot go back to a previous version of "dev-master" unless you know exactly which commit id you need and add this requirement to composer.json. But then you are in exactly the same situation as above requiring an exact version (a git tag is just a named alias for a commit id).

这篇关于运行composer install时如何解决两个包需求冲突?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！