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

问题描述

我要安装这两个套件：

• anahkiasen / former：dev-master


• vespakoen / menu：dev-master

但是作曲家说每个都取决于不同的版本

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

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

如何解决？

推荐答案

这里的基本问题是使用分支（dev-master）而不是标记的版本。使用分支很可能在问题中结束。我正在观看关于Stackoverflow的Composer问题，每当有人报告软件包问题时，他们在99％的时间使用开发分支和minimum-stability：dev。

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.

正确的事情是每个开发分支包括一个分支别名声明在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检测到包含所述版本在开发稳定性中）。

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.1 将需要1.1.0作为最低版本，并且不会更新到任何版本2.0.0。如果一个包被仔细地标记有根据语义版本的新版本，这就像一个魅力。你永远不会感到惊讶的不兼容的更改（除非当然人为干扰，但你应该能够检测到这个失败，并回滚更新如果你的软件断了）。

My personal preference is to use the tilde operator for versions: ~1.1 would require 1.1.0 as the minimum version, and would not update to any version 2.0.0. 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.1。* （据称会更新到所有即将发布的bug修复版本）或> = 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屋！