Github 上 composer/composer 的最新 issue 回應 https://github.com/composer/composer/issues Github 上 composer/composer 的最新 issue 回應 en-us Re: Shared library https://github.com/composer/composer/issues/664#issuecomment-636385408 You can check this plugin https://github.com/sup-ham/php-share https://github.com/composer/composer/issues/664#issuecomment-636385408 Sun, 31 May 2020 05:05:16 +0800 Re: Git::checkRefIsInMirror prevents https/git public usage https://github.com/composer/composer/issues/8932#issuecomment-636257261 Any change regarding COMPOSER_HOME behavior when not set? It seems it was defaulting to ~/.config/composer before but latest do not, leading to the unset config HOME. https://github.com/composer/composer/issues/8932#issuecomment-636257261 Sat, 30 May 2020 09:45:38 +0800 Re: Git::checkRefIsInMirror prevents https/git public usage https://github.com/composer/composer/issues/8932#issuecomment-636246857 2nd issue is why HOME is missing or does not make it at this stage inside composer. As it is defined and available before the call to GitDownloader. https://github.com/composer/composer/issues/8932#issuecomment-636246857 Sat, 30 May 2020 08:30:20 +0800 Re: Git::checkRefIsInMirror prevents https/git public usage https://github.com/composer/composer/issues/8932#issuecomment-636246324 Found the culprit. HOME env is not defined.<br /> <br /> ` - Installing env (master): PHP Notice: Undefined index: home in /home/pierre/projects/php/pickle/pickle/vendor/composer/composer/src/Composer/Config.php on line 279<br /> <br /> Notice: Undefined index: home in /home/pierre/projects/php/pickle/pickle/vendor/composer/composer/src/Composer/Config.php on line 279<br /> Cloning failed using an ssh key for authentication, enter your GitHub credentials to access private repos`<br /> <br /> So another issue, minor, but the notice should not happen.<br /> <br /> @Seldaek What behavior do you expect if HOME is missing? I can provide a PR https://github.com/composer/composer/issues/8932#issuecomment-636246324 Sat, 30 May 2020 08:26:54 +0800 Re: Where to place the composer.json file for Artifact? https://github.com/composer/composer/issues/8931#issuecomment-635912328 Yeah that sounds ok to me as a strictness cleanup for 2.0 https://github.com/composer/composer/issues/8931#issuecomment-635912328 Fri, 29 May 2020 19:02:28 +0800 Re: Git::checkRefIsInMirror prevents https/git public usage https://github.com/composer/composer/issues/8932#issuecomment-635886512 btw, doing git clone https://github.com/beberlei/env.git ../testext in the console work just fine. So it could be some operations called in this method that requires now auth https://github.com/composer/composer/issues/8932#issuecomment-635886512 Fri, 29 May 2020 17:58:02 +0800 Re: Where to place the composer.json file for Artifact? https://github.com/composer/composer/issues/8931#issuecomment-635881247 I think what would work for all archive types, not cause issues with the current state of things would be:<br /> <br /> - If there is a composer.json on the root level use it.<br /> - If there is a single directory containing a composer.json use it.<br /> <br /> All other cases would be invalid, so<br /> <br /> - no composer.json on root and multiple directories on top level: invalid<br /> - no composer.json on root and one directory containing exactly one other directory containing a composer.json: invalid https://github.com/composer/composer/issues/8931#issuecomment-635881247 Fri, 29 May 2020 17:45:43 +0800 Re: Where to place the composer.json file for Artifact? https://github.com/composer/composer/issues/8931#issuecomment-635877918 ## For metadata stage<br /> <br /> artifact repo reads from zip OR phar files, and indeed finds either root composer.json or shortest path. The point of the shortest path thing isn't to support files with multiple composer.json, it's just because github archives for example come nested within a folder like `reponame-shortCommitSha`, so we need to find the composer.json in there.<br /> <br /> No other repos look at archives of any kind IIRC.<br /> <br /> ## Download stage<br /> <br /> Then when installing dist packages, a few downloaders support archives:<br /> <br /> - ZipDownloader `zip`<br /> - TarDownloader `tar`, `tar.gz` or `tar.bz2` (uses PharData only, some of these need the right extensions loaded IIRC)<br /> - RarDownloader `rar`<br /> - GzipDownloader `gz` but it does not support extracting further so single files only<br /> - XzDownloader `xz` (requires system tar)<br /> - PharDownloader `phar` <br /> <br /> All of these inherit from ArchiveDownloader which will do the same as the above, i.e. extract and if only one directory is present after extraction, move the contents of that directory one level above to eliminate the top folder wrapping.<br /> <br /> Only zip is really used widely, the rest can be defined using package repos, so it has seen some use I'm sure but is definitely not as polished.<br /> <br /> ----<br /> <br /> I don't really think the behavior of Zip util needs changing as it works well as is.. I don't necessarily think it'd need to be replicated to other formats if we add support for other formats in ArtifactRepo, because it was a workaround for the github zip format mostly.<br /> https://github.com/composer/composer/issues/8931#issuecomment-635877918 Fri, 29 May 2020 17:37:50 +0800 Re: Where to place the composer.json file for Artifact? https://github.com/composer/composer/issues/8931#issuecomment-635864850 However, for the archive downloaders, they support having either the package content at the root, or having a single folder in the archive containing the content https://github.com/composer/composer/issues/8931#issuecomment-635864850 Fri, 29 May 2020 17:10:10 +0800 Re: Where to place the composer.json file for Artifact? https://github.com/composer/composer/issues/8931#issuecomment-635864282 Oh I didn't realize the artifact repository doesn't support .tar.gz/bz2 at all? https://github.com/composer/composer/issues/8931#issuecomment-635864282 Fri, 29 May 2020 17:09:02 +0800 Re: Where to place the composer.json file for Artifact? https://github.com/composer/composer/issues/8931#issuecomment-635863299 For other archives, the composer.json is not read from the archive at all. https://github.com/composer/composer/issues/8931#issuecomment-635863299 Fri, 29 May 2020 17:07:03 +0800 Re: Where to place the composer.json file for Artifact? https://github.com/composer/composer/issues/8931#issuecomment-635861701 More specifically: If there are multiple composer.json files in a zip file it currently picks the one with the shortest path, which seems pretty random/arbitrary. I'd be in favor of only supporting the json on the top two levels of directory and erroring if there is more than 1 composer.json on that level. However that would be a BC break, I'm just not sure if this actually matters to anyone right now, since you wouldn't currently even be able to control which composer.json of multiple would get used?<br /> <br /> @wissem Could you look into what exactly the behavior implemented for other archive types is? We should probably aim to have the same behavior for all types. https://github.com/composer/composer/issues/8931#issuecomment-635861701 Fri, 29 May 2020 17:03:44 +0800 Re: file_exists() is up to 100x slower then is_dir() or is_file() https://github.com/composer/composer/issues/8892#issuecomment-635800438 Ok closing this then, feel free to reopen/comment if there's a proven benefit. https://github.com/composer/composer/issues/8892#issuecomment-635800438 Fri, 29 May 2020 15:04:43 +0800 Re: file_exists() is up to 100x slower then is_dir() or is_file() https://github.com/composer/composer/issues/8892#issuecomment-635667593 No appreciable difference on 10000 files.<br /> <br /> Run on 12 year old hardware running ubuntu 18.<br /> is_file took 0.001291 ms<br /> file_exists took 0.001180 ms<br /> <br /> class Test {<br /> public function run() {<br /> $names = array();<br /> $handles = array();<br /> for ($i=0;$i<10000;$i++) {<br /> array_push($names, tempnam(sys_get_temp_dir(), "AAA"));<br /> array_push($handles, fopen($names[$i], "rw"));<br /> fwrite($handles[$i], "writing to tempfile\n");<br /> }<br /> <br /> $t0 = microtime(true);<br /> for ($i = 0; $i < 10000; $i++) { <br /> is_file($names[$i]);<br /> }<br /> $t1 = microtime(true);<br /> for ($i = 0; $i < 10000; $i++) {<br /> file_exists($names[$i]);<br /> }<br /> $t2 = microtime(true);<br /> printf("is_file took %f ms\n", ($t1 - $t0));<br /> printf("file_exists took %f ms\n", ($t2 - $t1));<br /> <br /> for ($i=0;$i<10000;$i++) {<br /> fclose($handles[$i]);<br /> unlink($names[$i]);<br /> }<br /> }<br /> }<br /> <br /> $t = new Test();<br /> $t->run();<br /> https://github.com/composer/composer/issues/8892#issuecomment-635667593 Fri, 29 May 2020 07:21:47 +0800 Re: PHP support strategy https://github.com/composer/composer/issues/8785#issuecomment-635623040 > I don't think you should be going against the long term support of distributions which are used not only on personal projects, but also from small scale companies to large scale enterprises and government institutions. Upgrades take time because software and user applications and projects need a lot of review and changes and money put into it, particularly when they are very customized.<br /> <br /> I don't think we should look at the versions those distributions include. They have their own resource to support these out-of-date php. We should look at which version the majority of modern frameworks/tools/libraries still support. <br /> <br /> [phpunit](https://phpunit.de/supported-versions.html): 7.2+ by 2021 Feb<br /> [symfony](https://symfony.com/releases): 5.5+ by 2021 Nov, then it jumps to 7.1+<br /> [codeigniter](https://codeigniter.com/download): 5.6+ EOL not specified. new version targets 7.2+<br /> [yii](https://www.yiiframework.com/release-cycle): 5.1+ by 2020 Dec 5.4+ for _Next release_ +2 years<br /> <br /> > These EOL service means these distros get security updates at least till those dates, meaning the systems are supported and secure by concept, so they are embraced by its users who have no reason to upgrade to newer systems, unless there is a radical change in software, which they won't consider likely for composer.<br /> <br /> If you are someone who really care about security, but you are still running old distributions version without updating php interpreter, it's highly possible that your framework will not get any updates, even security fix.<br /> https://github.com/composer/composer/issues/8785#issuecomment-635623040 Fri, 29 May 2020 05:40:20 +0800 Re: Bug: Composer solver bug in handling of `prefer-stable` sometimes allows update to unstable versions when it shouldn't https://github.com/composer/composer/issues/8882#issuecomment-635359708 it might change the order in which rules are processed in the solver, but there is absolutely no guarantee on that (that's internal implementation details, and it might depend on the whole set of rules adding in the project) https://github.com/composer/composer/issues/8882#issuecomment-635359708 Thu, 28 May 2020 21:45:21 +0800 Re: PHP support strategy https://github.com/composer/composer/issues/8785#issuecomment-635240404 IMO for composer 2.x i would expect PHP 5.6 and higher to be supported. <br /> Then in some years in a composer 3.x+ i would expect PHP 7.0 and higher to be supported.<br /> <br /> There are still many distribution releases that run PHP 5.6 or lower and are still supported.<br /> <br /> I don't think you should be going against the long term support of distributions which are used not only on personal projects, but also from small scale companies to large scale enterprises and government institutions. Upgrades take time because software and user applications and projects need a lot of review and changes and money put into it, particularly when they are very customized.<br /> <br /> Ubuntu: https://wiki.ubuntu.com/Releases<br /> - Ubuntu 20.04 Focal - ESM not set with PHP 7.4<br /> - Ubuntu 18.04 Bionic - ESM April 2028 with PHP 7.2<br /> - Ubuntu 16.04 Xenial - ESM April 2024 with PHP 7.0<br /> - Ubuntu 14.04 Trusty - ESM April 2022 with PHP 5.6<br /> <br /> Debian: https://wiki.debian.org/DebianReleases<br /> - 10 Buster - EOL LTS not set with PHP 7.3<br /> - 9 Stretch - EOL LTS ~2022 with PHP 7.0<br /> - 8 Jessie - EOL LTS ~2020-06-30 with PHP 5.6<br /> <br /> CentOS / RHEL: https://wiki.centos.org/About/Product<br /> - CentOS 8 - EOL Maintenance 2029-05 with PHP 7.2<br /> - CentOS 7 - EOL Maintenance 2024-06 with PHP 5.4<br /> - CentOS 6 - EOL Maintenance 2020-12 with PHP 5.3<br /> <br /> These EOL service means these distros get security updates at least till those dates, meaning the systems are supported and secure by concept, so they are embraced by its users who have no reason to upgrade to newer systems, unless there is a radical change in software, which they won't consider likely for composer.<br /> <br /> As you may note in these documentation pages, PHP 5.4-5.6 wont go anywhere until at least 2024 for CentOS and PHP 5.6 as well not before 2022 for Ubuntu.<br /> <br /> Sury provides additional PHP packages for Debian and Ubuntu - https://deb.sury.org/<br /> Remi provides additional PHP packages for CentOS and RHEL - https://rpms.remirepo.net/<br /> <br /> With those community non-official supported repos (which not all enterprise policies will allow) we can get PHP 5.6 across the board for all major distros on old releases.<br /> But we can't expect that for PHP 7.0+. https://github.com/composer/composer/issues/8785#issuecomment-635240404 Thu, 28 May 2020 17:52:31 +0800 Re: Cannot Resolve Host: getcomposer.org https://github.com/composer/composer/issues/2854#issuecomment-635234542 I got this error too https://github.com/composer/composer/issues/2854#issuecomment-635234542 Thu, 28 May 2020 17:40:12 +0800 Re: Composer is not trusting locally installed CAs on macOS https://github.com/composer/composer/issues/6427#issuecomment-635198966 With a small addition the [workaround](#issuecomment-487289643) for Mac OS X provided by @karudonaldson worked for me. I needed to append the company certificate to the `cert.pem` file. https://github.com/composer/composer/issues/6427#issuecomment-635198966 Thu, 28 May 2020 16:30:27 +0800 Re: [1.10] Fixed PHP 8 errors https://github.com/composer/composer/pull/8930#issuecomment-635160789 Fixed in https://github.com/composer/composer/commit/f7abfc9d7fb8437f1dee87f00c037d13279a6d16 already but thanks https://github.com/composer/composer/pull/8930#issuecomment-635160789 Thu, 28 May 2020 15:23:54 +0800 Re: Not POSIX compliant: short option -d expects parameter without whitespace https://github.com/composer/composer/issues/8927#issuecomment-634698380 My bad, didn't notice help said:<br /> <br /> ```<br /> Usage:<br /> command [options] [arguments]<br /> ```<br /> <br /> Thanks for pointing this out.<br /> <br /> `composer install -d /foo/bar/myproject` is working as expected. https://github.com/composer/composer/issues/8927#issuecomment-634698380 Wed, 27 May 2020 22:28:35 +0800 Re: Not POSIX compliant: short option -d expects parameter without whitespace https://github.com/composer/composer/issues/8927#issuecomment-634696626 IIRC, things work as expected if you put the name of the composer command (`install` in that case) before the options. The issue being that symfony/console needs to know which command is being run before being able to parse the options (to know whether `-d` expects a value or is a simple flag), as each command can have different options. https://github.com/composer/composer/issues/8927#issuecomment-634696626 Wed, 27 May 2020 22:25:55 +0800 Re: Compile & compact constraints https://github.com/composer/composer/pull/8926#issuecomment-634452349 Ok so it's not worth it for the places I put it on it seems. Still might come in handy for #8850, we'll see. But IMO we could merge the compilation at least, that seems fairly risk free and definitely improves perf. https://github.com/composer/composer/pull/8926#issuecomment-634452349 Wed, 27 May 2020 14:16:45 +0800 Re: Compile & compact constraints https://github.com/composer/composer/pull/8926#issuecomment-634277613 From my test (on magento)<br /> <br /> snapshot: [13.2s](https://blackfire.io/profiles/74d4a167-21d2-45b1-be0a-9fce5c196f37/graph)<br /> compiling+compacting: [11.3s](https://blackfire.io/profiles/91df325d-438f-404f-91d8-6942d77e24f7/graph)<br /> compiling only: [10.5s](https://blackfire.io/profiles/efda6de3-f9e7-4392-b401-d480995f8be5/graph)<br /> <br /> note: `Intervals::compactConstraint` method is called 12,241 times but in only 76 cases it generates a constraint different from the original one https://github.com/composer/composer/pull/8926#issuecomment-634277613 Wed, 27 May 2020 05:02:55 +0800 Re: Use compiled constraint in Composer https://github.com/composer/composer/pull/8845#issuecomment-634269672 closed in favor of #8926 https://github.com/composer/composer/pull/8845#issuecomment-634269672 Wed, 27 May 2020 04:46:06 +0800 Re: composer/semver 2.1@dev required but does not exist https://github.com/composer/composer/issues/8922#issuecomment-634208068 composer/semver 3.0.0 stable is now out, which the latest composer dev-master requires. Just FYI. https://github.com/composer/composer/issues/8922#issuecomment-634208068 Wed, 27 May 2020 02:46:32 +0800 Re: composer/semver 2.1@dev required but does not exist https://github.com/composer/composer/issues/8922#issuecomment-633952812 Just require the appropriate version, i.e. `"composer/semver": "^2.1@dev",`, or simply `"composer/semver": "@dev"` which is enough to allow it to be installed in dev, but doesn't strictly specify a preference on which version, if you are not requiring it from your package.<br /> <br /> https://github.com/composer/composer/issues/8922#issuecomment-633952812 Tue, 26 May 2020 18:52:21 +0800 Re: Command to remove redundant dependencies (those already required by other requirements) from top-level composer.json https://github.com/composer/composer/issues/8925#issuecomment-633649774 To clarify, *all code would be in a dependency*. My request is not going against recommendation that any package used in my code should appear in my requirements. Our use case is a Drupal distribution which may be why it seems a little odd to other uses. Root project brings in Project A. Root project brings in Project B during development. Project A is updated to require Project B. There is no dependency in the root project on project B directly, and automated help to clean up the root project composer file to reflect this (only listing a requirement on Project A) would be useful. https://github.com/composer/composer/issues/8925#issuecomment-633649774 Tue, 26 May 2020 00:48:30 +0800 Re: Command to remove redundant dependencies (those already required by other requirements) from top-level composer.json https://github.com/composer/composer/issues/8925#issuecomment-633625242 Well, the best practice is that any package that you use directly in your own code should appear in your own requirement rather than relying on transitive dependencies (because these transitive dependencies might change, either being removed or bumping to a new major version, which could then break your own code).<br /> Given that the suggested command goes explicitly against this recommendation, I don't think it belongs to the core. https://github.com/composer/composer/issues/8925#issuecomment-633625242 Mon, 25 May 2020 23:34:43 +0800 Re: The "https://repo.packagist.org/package.json" file could not be downloaded: failed to open stream: Address not available https://github.com/composer/composer/issues/8889#issuecomment-633583428 The same issue here. Failed on random repo.packagist.org URLs:<br /> ```<br /> composer install --no-scripts --no-autoloader --ignore-platform-reqs -vvv<br /> ---> Running in 7e03b0c4ce6e<br /> Reading ./composer.json<br /> Loading config file ./composer.json<br /> Checked CA file /etc/ssl/certs/ca-certificates.crt: valid<br /> Executing command (/app): git branch --no-color --no-abbrev -v<br /> Executing command (/app): git describe --exact-match --tags<br /> Executing command (/app): git log --pretty="%H" -n1 HEAD<br /> Executing command (/app): hg branch<br /> Executing command (/app): fossil branch list<br /> Executing command (/app): fossil tag list<br /> Executing command (/app): svn info --xml<br /> Failed to initialize global composer: Composer could not find the config file: /tmp/composer.json<br /> To initialize a project, please create a composer.json file as described in the https://getcomposer.org/ "Getting Started" section<br /> Running 1.10.6 (2020-05-06 10:28:10) with PHP 7.4.6 on Linux / 5.0.0-1034-gcp<br /> Loading composer repositories with package information<br /> Downloading https://repo.packagist.org/packages.json<br /> Writing /tmp/cache/repo/https---repo.packagist.org/packages.json into cache<br /> Updating dependencies (including require-dev)<br /> Downloading https://repo.packagist.org/p/provider-2013%2439889488e431198f82366f24d4b180f004da7736a9d8f247d692e2f180d2dbb5.json<br /> Writing /tmp/cache/repo/https---repo.packagist.org/p-provider-2013.json into cache<br /> Downloading https://repo.packagist.org/p/provider-2014%24c8c7850ee585d741df818789bf7245903e3d5d3a4c7b4a9ecd4fa7b937334838.json<br /> Writing /tmp/cache/repo/https---repo.packagist.org/p-provider-2014.json into cache<br /> Downloading https://repo.packagist.org/p/provider-2015%240a81c61715cbe907f07fbc9382e86b3745152629f4840c2986ef92c4af96c4ff.json<br /> Writing /tmp/cache/repo/https---repo.packagist.org/p-provider-2015.json into cache<br /> Downloading https://repo.packagist.org/p/provider-2016%24302f4e0d31b914debced4d53e187c50fd93f2936e1b2167b0439f94f01983fd2.json<br /> Writing /tmp/cache/repo/https---repo.packagist.org/p-provider-2016.json into cache<br /> Downloading https://repo.packagist.org/p/provider-2017%24b16ea8197f0bccfbf3d40d753ff1a09bb307ac085e28d6eccc18649074097df0.json<br /> Writing /tmp/cache/repo/https---repo.packagist.org/p-provider-2017.json into cache<br /> Downloading https://repo.packagist.org/p/provider-2018%246c281c1cb6fb2912ed91e86dc7230ced9fb4eb804c75fc2d5e82804d3d55fa61.json<br /> Writing /tmp/cache/repo/https---repo.packagist.org/p-provider-2018.json into cache<br /> Downloading https://repo.packagist.org/p/provider-2019%2436f6e42552220bb63d0f7982afb37287d0823fe219f5691efada2ecd3b99ce76.json<br /> Writing /tmp/cache/repo/https---repo.packagist.org/p-provider-2019.json into cache<br /> Downloading https://repo.packagist.org/p/provider-2019-07%24497cdf20ddb4ba61a3d3dbe6440f4dbdc7fb309ebb973a8858ff2b847a06fce6.json<br /> <br /> ```<br /> ```<br /> Downloading https://repo.packagist.org/p/symfony/polyfill-intl-grapheme%24f97b9661fe500a4a64b319bf0dc178f8fab92b0f2b7171ad57fbfbe0adbc816e.json<br /> Writing /tmp/cache/repo/https---repo.packagist.org/provider-symfony$polyfill-intl-grapheme.json into cache<br /> Downloading https://repo.packagist.org/p/symfony/polyfill-intl-normalizer%249fda95e57e0b29072e7d239fbb0e487c326ed80e32ec3f3b7a0959a69ba54b5d.json<br /> Writing /tmp/cache/repo/https---repo.packagist.org/provider-symfony$polyfill-intl-normalizer.json into cache<br /> Downloading https://repo.packagist.org/p/symfony/translation-contracts%24502145946101de780ffabf4a1aef7971ff8a4254c6e68466fdcdb73e830e1f63.json<br /> Downloading https://repo.packagist.org/p/symfony/translation-contracts%24502145946101de780ffabf4a1aef7971ff8a4254c6e68466fdcdb73e830e1f63.json<br /> Downloading https://repo.packagist.org/p/symfony/translation-contracts%24502145946101de780ffabf4a1aef7971ff8a4254c6e68466fdcdb73e830e1f63.json<br /> <br /> <br /> [Composer\Downloader\TransportException] <br /> The "https://repo.packagist.org/p/symfony/translation-contracts%24502145946101de780ffabf4a1aef7971ff8a4254c6e68466fdcdb73e830e1f63.json" file could not be downloaded: failed to open stream: Address not available <br /> <br /> <br /> Exception trace:<br /> () at phar:///usr/bin/composer/src/Composer/Util/RemoteFilesystem.php:560<br /> Composer\Util\RemoteFilesystem->get() at phar:///usr/bin/composer/src/Composer/Util/RemoteFilesystem.php:105<br /> Composer\Util\RemoteFilesystem->getContents() at phar:///usr/bin/composer/src/Composer/Repository/ComposerRepository.php:695<br /> Composer\Repository\ComposerRepository->fetchFile() at phar:///usr/bin/composer/src/Composer/Repository/ComposerRepository.php:366<br /> Composer\Repository\ComposerRepository->whatProvides() at phar:///usr/bin/composer/src/Composer/DependencyResolver/Pool.php:204<br /> Composer\DependencyResolver\Pool->computeWhatProvides() at phar:///usr/bin/composer/src/Composer/DependencyResolver/Pool.php:193<br /> Composer\DependencyResolver\Pool->whatProvides() at phar:///usr/bin/composer/src/Composer/DependencyResolver/RuleSetGenerator.php:164<br /> Composer\DependencyResolver\RuleSetGenerator->whitelistFromPackage() at phar:///usr/bin/composer/src/Composer/DependencyResolver/RuleSetGenerator.php:304<br /> Composer\DependencyResolver\RuleSetGenerator->whitelistFromJobs() at phar:///usr/bin/composer/src/Composer/DependencyResolver/RuleSetGenerator.php:355<br /> Composer\DependencyResolver\RuleSetGenerator->getRulesFor() at phar:///usr/bin/composer/src/Composer/DependencyResolver/Solver.php:217<br /> Composer\DependencyResolver\Solver->solve() at phar:///usr/bin/composer/src/Composer/Installer.php:489<br /> Composer\Installer->doInstall() at phar:///usr/bin/composer/src/Composer/Installer.php:232<br /> Composer\Installer->run() at phar:///usr/bin/composer/src/Composer/Command/InstallCommand.php:122<br /> Composer\Command\InstallCommand->execute() at phar:///usr/bin/composer/vendor/symfony/console/Command/Command.php:245<br /> Symfony\Component\Console\Command\Command->run() at phar:///usr/bin/composer/vendor/symfony/console/Application.php:835<br /> Symfony\Component\Console\Application->doRunCommand() at phar:///usr/bin/composer/vendor/symfony/console/Application.php:185<br /> Symfony\Component\Console\Application->doRun() at phar:///usr/bin/composer/src/Composer/Console/Application.php:281<br /> Composer\Console\Application->doRun() at phar:///usr/bin/composer/vendor/symfony/console/Application.php:117<br /> Symfony\Component\Console\Application->run() at phar:///usr/bin/composer/src/Composer/Console/Application.php:113<br /> Composer\Console\Application->run() at phar:///usr/bin/composer/bin/composer:61<br /> require() at /usr/bin/composer:24<br /> <br /> install [--prefer-source] [--prefer-dist] [--dry-run] [--dev] [--no-dev] [--no-custom-installers] [--no-autoloader] [--no-scripts] [--no-progress] [--no-suggest] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--ignore-platform-reqs] [--] [<packages>]...<br /> <br /> The command '/bin/sh -c composer install --no-scripts --no-autoloader --ignore-platform-reqs -vvv' returned a non-zero code: 1<br /> ``` https://github.com/composer/composer/issues/8889#issuecomment-633583428 Mon, 25 May 2020 21:52:20 +0800