作曲家为什么要降级我的包裹？ [英] Why did composer downgrade my packages?

问题描述

php composer.phar更新做到了这一点（删除了2.3.0软件包并安装了整个2.2.5 Zend Framework）：

php composer.phar update did this (removed 2.3.0 packages and installed entire 2.2.5 Zend Framework):

$ php composer.phar update
Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Removing zendframework/zend-filter (2.3.0)
  - Removing zendframework/zend-view (2.3.0)
  - Removing zendframework/zend-eventmanager (2.3.0)
  - Removing zendframework/zend-loader (2.3.0)
  - Removing zendframework/zend-escaper (2.3.0)
  - Removing zendframework/zend-log (2.3.0)
  - Removing zendframework/zend-servicemanager (2.3.0)
  - Removing zendframework/zend-stdlib (2.3.0)
  - Installing zendframework/zendframework (2.2.5)
    Loading from cache
Writing lock file
Generating autoload files

为什么这样做？我的composer.json看起来像这样，并没有建议任何指示上述事件过程的类型：

Why did it do that? My composer.json looks like this and suggests nothing of the sort that directed the above course of events:

"repositories":[
    {
        "type":"composer",
        "url":"https://packagist.org/"
    },
    {
         "type":"composer",
         "url":"http://packages.zendframework.com/"
    }
],
"require": {
    "zendframework/zend-log" : "2.*",
    "zendframework/zend-escaper" : "2.*",
    "zendframework/zend-filter" : "2.*",
    "zendframework/zend-view" : "2.*"
}

我的期望是：删除2.3.0，安装2.3.1程序包

My expectation was: remove 2.3.0, install 2.3.1 packages

推荐答案

我的回答不太能描述为什么进行了降级，因为Composer中的算法非常密集（这就是 update 花费比 install更长的时间的原因 ing with .lock ）。它们会遍历您的所有依赖项，所有潜在版本以及每个依赖项的版本的依赖项。在获得所有这些信息之后，它会尝试提出一个完美的匹配。

My answer doesn't quite describe why it was downgraded, since the algorithms in Composer are quite intensive (that is why update takes way longer than installing with a .lock). They go through all of your dependencies, all of the potential versions, and what each dependencies' versions' dependencies are. After getting all of this information it tries to come up with a "perfect" match.

有时候，您的依存关系或依存关系的依存关系中的丝毫变化，可能会造成巨大的变化。 。另外，您有时会看到无法解决依赖关系，因为一种依赖关系可能需要 symfony / http-foundation〜2.5 ，而另一种依赖关系可能需要 symfony / http-foundation 2.1。* （这不是您的情况，但是很高兴知道）。

Sometimes the slightest change in your dependencies, or a dependency's dependencies, can create drastic changes. Also, you'll sometimes see that it is impossible to resolve your dependencies because one dependency may require symfony/http-foundation ~2.5 and one may require symfony/http-foundation 2.1.* (this isn't what happened in your case, but it is good to know).

全部总而言之，故事的寓意是，您应该对您的 composer.json （尤其是在制作中）尽可能具体。这样，您始终可以控制使用的版本，而不是由Composer决定。更糟糕的是，您运行的是 composer更新，它无法解决您的依赖关系。然后对 Packagist 进行一些研究，看看哪些版本可以一起愉快地解决。

All in all, the moral of the story is you should be as specific as possible with your composer.json (especially in production). That way, you can always be in control of what version you use rather than letting Composer decide. Worse case, is you run a composer update and it cannot resolve your dependencies. Then do some research on Packagist to see which versions will happily resolve together.

我建议使用任一版本〜2.3 （与> = 2.3 和<$相同c $ c>< 3 ）或 2.3。* 。然后，Composer甚至不会尝试使用 2.2.5 版本。查看作曲家的文档，了解如何表达不同的包版本。

I suggest using either version ~2.3 (which is the same as >= 2.3 and < 3) or 2.3.*. Then Composer won't even try version 2.2.5. Check Composer's documentation to see how you can express different package versions.

这篇关于作曲家为什么要降级我的包裹？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！