php 尽管有 --prefer-dist 标志，但作曲家依赖项的更新缓慢
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/19316650/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Slow updating of composer dependencies, despite --prefer-dist flag
提问by Jonathan
Why does it take up to two minutes for my composer dependencies to update, even when there have been no changes?
为什么我的 Composer 依赖项最多需要两分钟才能更新，即使没有更改？
A popular suggestionis to add the --prefer-distflag, which I've appended to my command:
一个流行的建议是添加--prefer-dist标志，我已将其附加到我的命令中：
php composer.phar update --prefer-dist
But this makes no difference. Below is my composer.json file - am I missing something obvious?
但这没什么区别。下面是我的 composer.json 文件 - 我是否遗漏了一些明显的东西？
{
"name": "my-namespace/symfony",
"type": "project",
"description": "",
"require": {
"php": ">=5.3.3",
"symfony/symfony": "2.3.*",
"doctrine/orm": ">=2.2.3,<2.4-dev",
"doctrine/doctrine-bundle": "1.2.*",
"twig/extensions": "1.0.*",
"symfony/assetic-bundle": "2.3.*",
"symfony/monolog-bundle": "2.3.*",
"sensio/framework-extra-bundle": "2.3.*",
"sensio/generator-bundle": "2.3.*",
"sensio/distribution-bundle": "2.2.*",
"my-namespace/my-bundle": "1.0.*"
},
"repositories": [
{
"type": "vcs",
"url": "http://username:[email protected]/my-bundle.git"
}
],
"scripts": {
"post-install-cmd": [
"Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::buildBootstrap",
"Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::clearCache",
"Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::installAssets",
"Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::installRequirementsFile"
],
"post-update-cmd": [
"Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::buildBootstrap",
"Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::clearCache",
"Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::installAssets",
"Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::installRequirementsFile"
]
},
"config": {
"bin-dir": "bin"
},
"minimum-stability": "dev",
"extra": {
"symfony-app-dir": "app",
"symfony-web-dir": "web",
"branch-alias": {
"dev-master": "2.3-dev"
}
}
}
回答by Nicolai Fr?hlich
This problem is often related to xdebug being loaded in your CLI environment. (It doesn't matter if xdebug is enabled or not.)
此问题通常与在 CLI 环境中加载的 xdebug 相关。（是否启用 xdebug 并不重要。）
You can check whether xdebug is enabled using one of the followinc commands.
您可以使用以下命令之一检查是否启用了 xdebug。
// Unix
php -m | grep xdebug
// Windows
php -m | findstr xdebug
Further information on what operations take so long can be gained by enabling maximum verbosity and profiling information. (Replace installwith updateif you are updating the packages.)
通过启用最大程度的详细信息和分析信息，可以获得有关哪些操作需要这么长时间的更多信息。（更换安装与更新，如果你正在更新包。）
composer install --prefer-dist -vvv --profile
回答by alcohol
Factors that can slow down Composer:
可能会降低 Composer 速度的因素：
As pointed out,
xdebugcan affect the performance of Composer. Runningcomposer diagnosewill also warn you about this.Running
updateinstead ofinstall. People too often just runupdateconstantly. This makes Composer go through the entire dependency resolving process, regardless of whether or not anything has changed. When you runinstall, Composer takes the requirements directly from your .lock file, skipping the dependency resolving process. You should only runupdateduring the development lifecycle of your application. And even then, it's not something you have to run daily usually.If you have a specific dependency that you update frequently yourself, you could try simplifying the process by running
composer update vendor/package --with-dependenciesinstead.Setting
minimum-stabilitytodev. This greatly expands the amount of possibilities that the dependency resolver has to consider. You should almost never lower theminimum-stabilitytodevunless you absolutely have no other choice. Look into alternatives, such as temporarily using a inline@devflag.
正如指出的那样，
xdebug会影响 Composer 的性能。跑步composer diagnose也会警告你这一点。运行
update而不是install. 人们往往只是update不停地奔跑。这使得 Composer 经历了整个依赖解析过程，无论是否发生任何变化。当您运行 时install，Composer 直接从您的 .lock 文件中获取需求，跳过依赖项解析过程。您应该只update在应用程序的开发生命周期内运行。即便如此，这也不是您通常每天必须运行的东西。如果您有自己经常更新的特定依赖项，则可以尝试通过运行
composer update vendor/package --with-dependencies来简化流程。设置
minimum-stability为dev. 这极大地扩展了依赖解析器必须考虑的可能性。除非您绝对别无选择minimum-stability，dev否则您几乎不应该降低到。寻找替代方案，例如临时使用内联@dev标志。
回答by Rai
Seems like the problem was resolved, but this might help someone.
似乎问题已解决，但这可能对某人有所帮助。
Whenever I ran composer install or update, it took more than 10 seconds just to fetch the https://packagist.org/packages.jsonfile. Eventually I found out that the problem was related to IPv6, since fetching files from IPv4 sites took less than a second.
The problem is that my ISP doesn't support IPv6, but I had it enabled in my ethernet properties. After I unticked Internet Protocol Version 6 (TCP/IPv6)in my network settings, install/update speeds drastically improved (dropped from 200+ seconds to like 10)
每当我运行 composer install 或 update 时，仅获取https://packagist.org/packages.json文件就需要超过 10 秒的时间。最终我发现问题与 IPv6 有关，因为从 IPv4 站点获取文件只用了不到一秒钟的时间。
问题是我的 ISP 不支持 IPv6，但我在以太网属性中启用了它。在我取消Internet Protocol Version 6 (TCP/IPv6)网络设置后，安装/更新速度大大提高（从 200+ 秒下降到 10 秒）
回答by John Sampson
I was having this issue while running Symfony2 on a VM that had low memory. I increased the machine's memory and it improved drastically. You may check the memory on your system and see if it can be upgraded.
我在内存不足的 VM 上运行 Symfony2 时遇到了这个问题。我增加了机器的内存，它大大改善了。您可以检查系统上的内存，看看它是否可以升级。
回答by Sven
You are using a private repository. This will not allow to download zipped version of the version you include, but must clone the repository. Additionally, it might be that the whole repository must be scanned to find the required version.
您正在使用私有存储库。这将不允许下载您包含的版本的压缩版本，但必须克隆存储库。此外，可能必须扫描整个存储库才能找到所需的版本。
You should check whether using Satis is an option. That way you could prepare ZIPs of your own software and download it just like the things hosted on Github (which has an API for this that is used by Composer to allow downloading ZIPs even if they are not explicitly prepared).
您应该检查是否可以选择使用 Satis。这样你就可以准备你自己的软件的 ZIP 并下载它，就像 Github 上托管的东西一样（它有一个 API，Composer 使用它来允许下载 ZIP，即使它们没有明确准备）。
回答by ako
I had same issue with composer update, I updated composer itself to the latest version using composer selfupdateand now it's speed acceptable.
我遇到了同样的问题composer update，我使用 将作曲家本身更新到最新版本composer selfupdate，现在它的速度可以接受。
回答by Stian S
Check if zipand unzipare installed. If they are missing, Composer will clone the repo instead of downloading a zipped release.
检查zip和unzip是否已安装。如果它们丢失，Composer 将克隆存储库而不是下载压缩版本。
回答by Saeven
Indeed, xdebug is certainly going to slow things down. Uninstalling xdebug is not ideal though. A good option is to use HHVM and put it on composer duty.
事实上，xdebug 肯定会减慢速度。不过，卸载 xdebug 并不理想。一个不错的选择是使用 HHVM 并将其置于作曲家的职责中。
Installing HHVM is pretty painless, and HHVM itself is much more rapid than PHP5. It's a double-win -- YMMV, but I got near-5x speed increase (on the eyeball dyno admittedly) in the composer usage I'd get even if xdebug weren't in the picture.
安装 HHVM 非常轻松，而且 HHVM 本身比 PHP5 快得多。这是双赢 - YMMV，但即使 xdebug 不在图片中，我也会在作曲家使用中获得近 5 倍的速度增加（在眼球测功机上）。
If you are on OS X, then this link might help (blog article I wrote on the matter):
如果您使用的是 OS X，那么此链接可能会有所帮助（我就此事撰写的博客文章）：
