Github 上 composer/composer 的最新 issue 回應 https://github.com/composer/composer/issues Github 上 composer/composer 的最新 issue 回應 en-us Re: Inconsistent handling of dependencies that do not support PHP 8 when PHP 8 is used https://github.com/composer/composer/issues/9107#issuecomment-670393678 @stof Thank you for the clarification. This makes sense, of course. https://github.com/composer/composer/issues/9107#issuecomment-670393678 Fri, 07 Aug 2020 16:15:49 +0800 Re: Inconsistent handling of dependencies that do not support PHP 8 when PHP 8 is used https://github.com/composer/composer/issues/9107#issuecomment-670392320 the reason is here: https://github.com/sebastianbergmann/phpunit/blob/0da9c632608427dbb99b1cb443c9f1944d2f8be3/composer.json#L56-L59 https://github.com/composer/composer/issues/9107#issuecomment-670392320 Fri, 07 Aug 2020 16:12:29 +0800 Re: autoload_files not to loaded on script runs https://github.com/composer/composer/issues/4764#issuecomment-670066178 @greg-1-anderson alternatively I or someone else can create a plugin to do that :) https://github.com/composer/composer/issues/4764#issuecomment-670066178 Fri, 07 Aug 2020 01:21:59 +0800 Re: autoload_files not to loaded on script runs https://github.com/composer/composer/issues/4764#issuecomment-670043814 @Seldaek You could still do:<br /> <br /> > 3. Enhance Composer to allow the top-level composer.json to declare which projects' autoload files should be included for Composer scripts (guzzlehttp/guzzle, guzzlehttp/psr7 and guzzlehttp/promises in this example).<br /> <br /> If Composer only autoloaded files when the top-level composer.json opted in, then folks could add that if they needed to use Guzzle from a Composer script, but other projects wouldn't break.<br /> <br /> Not super high priority IMO, but might be nice. https://github.com/composer/composer/issues/4764#issuecomment-670043814 Fri, 07 Aug 2020 00:43:20 +0800 Re: Still get error in alpha 3 (just in one site) https://github.com/composer/composer/issues/9104#issuecomment-670034380 So drupal/core does work sometimes with Composer 2. It never worked with alpha 2 https://github.com/composer/composer/issues/9104#issuecomment-670034380 Fri, 07 Aug 2020 00:26:40 +0800 Re: Still get error in alpha 3 (just in one site) https://github.com/composer/composer/issues/9104#issuecomment-670030585 Composer 2 worked in 4 other sites, but fails in 2 of them<br /> And by the way, when this happens, <br /> composer self-update --rollback<br /> fails with the same error.<br /> But composer _self-update_ rolls it back luckily https://github.com/composer/composer/issues/9104#issuecomment-670030585 Fri, 07 Aug 2020 00:20:02 +0800 Re: Still get error in alpha 3 (just in one site) https://github.com/composer/composer/issues/9104#issuecomment-670025016 The error happens in `Drupal\Core\Composer\Composer::vendorTestCodeCleanup`. It looks like drupal/core is not yet compatible with Composer 2. https://github.com/composer/composer/issues/9104#issuecomment-670025016 Fri, 07 Aug 2020 00:10:43 +0800 Re: backport the legacy event api that allowed the substitue of rfs https://github.com/composer/composer/pull/8807#issuecomment-670021801 Ok thanks! https://github.com/composer/composer/pull/8807#issuecomment-670021801 Fri, 07 Aug 2020 00:04:57 +0800 Re: autoload_files not to loaded on script runs https://github.com/composer/composer/issues/4764#issuecomment-669742742 Yeah this is something that can't really be fixed IMO at this point due to the amount of packages which might rely on the existing behavior. https://github.com/composer/composer/issues/4764#issuecomment-669742742 Thu, 06 Aug 2020 14:55:31 +0800 Re: autoload_files not to loaded on script runs https://github.com/composer/composer/issues/4764#issuecomment-669328251 Hmm ok, my personal use would be during the `pre-autoload-dump` event tho. But I suppose the same reasoning applies there? https://github.com/composer/composer/issues/4764#issuecomment-669328251 Thu, 06 Aug 2020 01:33:33 +0800 Re: autoload_files not to loaded on script runs https://github.com/composer/composer/issues/4764#issuecomment-669318044 v2 does not change this.<br /> <br /> The hard point here is that the autoloader for script is regenerated many times (due to having a `post-package-install` hook running after each package is installed and needing to know about the packages installed at this point). This makes it hard to deal with file includes (we cannot include the same file multiple times, otherwise PHP will break, but we might also have conflicts between function definitions between 2 different versions of a package, with the old one being removed and the new one being installed, at some point of the process) https://github.com/composer/composer/issues/4764#issuecomment-669318044 Thu, 06 Aug 2020 01:12:28 +0800 Re: autoload_files not to loaded on script runs https://github.com/composer/composer/issues/4764#issuecomment-669314827 > We could easily include all the autoload_files I guess but that means they MUST support being included multiple times, which I doubt is the case right now, so we would probably break a bunch of projects.<br /> <br /> @Seldaek any change this will be fixed in v2 or v3? https://github.com/composer/composer/issues/4764#issuecomment-669314827 Thu, 06 Aug 2020 01:06:03 +0800 Re: Allow installing from lock https://github.com/composer/composer/issues/9102#issuecomment-669036877 Maybe my issue is that the CI starts from an empty vendor folder?<br /> <br /> I believe `npm ci` empties the dependencies folder so it does not have to worry about which dependencies were installed. https://github.com/composer/composer/issues/9102#issuecomment-669036877 Wed, 05 Aug 2020 15:42:38 +0800 Re: Allow installing from lock https://github.com/composer/composer/issues/9102#issuecomment-668982015 It still needs to figure out what needs installing/updating/removing between the vendor directory and the state of the lock file, which is done using the solver, but using no network and so few packages that it is typically resolving within milliseconds. https://github.com/composer/composer/issues/9102#issuecomment-668982015 Wed, 05 Aug 2020 13:05:07 +0800 Re: Allow installing from lock https://github.com/composer/composer/issues/9102#issuecomment-668774191 Why does it need to resolve dependencies if every needed package is listed in the lock file with its exact version? https://github.com/composer/composer/issues/9102#issuecomment-668774191 Wed, 05 Aug 2020 03:10:29 +0800 Re: Allow installing from lock https://github.com/composer/composer/issues/9102#issuecomment-668601142 As per the piece of truncated text that follows, "but Composer uses the exact versions listed in composer.lock". So composer install if the lock file is present should be very fast, at least the solving step. The install can still take a while if you have a ton of packages to download/extract. https://github.com/composer/composer/issues/9102#issuecomment-668601142 Tue, 04 Aug 2020 21:36:41 +0800 Re: Fix the example link for the list endpoint https://github.com/composer/composer/pull/9101#issuecomment-667954314 Ah thanks https://github.com/composer/composer/pull/9101#issuecomment-667954314 Mon, 03 Aug 2020 18:50:42 +0800 Re: Properly support PHP 8.0 Named Arguments (Fatal error: Uncaught ArgumentCountError: array_merge() does not accept unknown named parameters) https://github.com/composer/composer/pull/9076#issuecomment-667924913 Now https://github.com/composer/composer/releases/tag/1.10.10 https://github.com/composer/composer/pull/9076#issuecomment-667924913 Mon, 03 Aug 2020 17:46:57 +0800 Re: gitlab-token not used when specifying "package" repositories https://github.com/composer/composer/issues/9099#issuecomment-667711885 It looks like composer IS setting the header, but gitlab.com doesn't wanna read it... I guess I will have to use a different endpoint... https://github.com/composer/composer/issues/9099#issuecomment-667711885 Mon, 03 Aug 2020 03:01:57 +0800 Re: Expand library version checking capabilities https://github.com/composer/composer/pull/9093#issuecomment-667694263 I've set up this little data donation script to crowdsource more test data: https://usrportage.de/composer-data-donation/ https://github.com/composer/composer/pull/9093#issuecomment-667694263 Mon, 03 Aug 2020 00:19:27 +0800 Re: Properly support PHP 8.0 Named Arguments (Fatal error: Uncaught ArgumentCountError: array_merge() does not accept unknown named parameters) https://github.com/composer/composer/pull/9076#issuecomment-667652450 @Seldaek Do you have an ETA for a new 1.10 release that has this fix? Thanks! https://github.com/composer/composer/pull/9076#issuecomment-667652450 Sun, 02 Aug 2020 17:47:24 +0800 Re: Fatal error: Uncaught ArgumentCountError: array_merge() does not accept unknown named parameters https://github.com/composer/composer/issues/9097#issuecomment-667643131 Thank you, Nikita! Somehow #9076 did not show up in my search. https://github.com/composer/composer/issues/9097#issuecomment-667643131 Sun, 02 Aug 2020 16:04:33 +0800 Re: Fatal error: Uncaught ArgumentCountError: array_merge() does not accept unknown named parameters https://github.com/composer/composer/issues/9097#issuecomment-667642697 This has already been fixed in #9076. It's (the only) expected breakage from named parameters. https://github.com/composer/composer/issues/9097#issuecomment-667642697 Sun, 02 Aug 2020 15:59:52 +0800 Re: Fatal error: Uncaught ArgumentCountError: array_merge() does not accept unknown named parameters https://github.com/composer/composer/issues/9097#issuecomment-667642368 I am almost certain that this is nothing that can/should be fixed in Composer, but that this is rather an issue in PHP 8.<br /> <br /> @nikic What do you think? https://github.com/composer/composer/issues/9097#issuecomment-667642368 Sun, 02 Aug 2020 15:56:29 +0800 Re: Composer 2x: Composer plugins vs PackageEvents::PRE_PACKAGE_INSTALL https://github.com/composer/composer/issues/9079#issuecomment-667509725 Looks like my assumption is correct, the latest Composer 1x version installs patches from a `composer-plugin` automatically which means `PackageEvents::PRE_PACKAGE_INSTALL` is triggered.<br /> <br /> [composer install 1.10.9.txt](https://github.com/composer/composer/files/5010240/composer.install.1.10.9.txt)<br /> https://github.com/composer/composer/issues/9079#issuecomment-667509725 Sat, 01 Aug 2020 18:27:12 +0800 Re: Expand library version checking capabilities https://github.com/composer/composer/pull/9093#issuecomment-667207921 Now the test coverage should be pretty good plus added a huge test suite for converting OpenSSL versions to something sensible.<br /> <br /> Ready for review now https://github.com/composer/composer/pull/9093#issuecomment-667207921 Sat, 01 Aug 2020 00:17:38 +0800 Re: Github complains that composer 1.9.1 use of oauth token will soon be deprecated https://github.com/composer/composer/issues/9095#issuecomment-667130803 1.9.3 fixed this https://github.com/composer/composer/releases/tag/1.9.3 - please run up to date software. https://github.com/composer/composer/issues/9095#issuecomment-667130803 Fri, 31 Jul 2020 21:52:37 +0800 Re: Composer 2x: Composer plugins vs PackageEvents::PRE_PACKAGE_INSTALL https://github.com/composer/composer/issues/9079#issuecomment-667128919 New theory: Maybe the actual problem is that the [Pronovix/drupal-qa](https://github.com/Pronovix/drupal-qa) is a `composer-plugin` and it is handled differently than a `library` or a `drupal-module` when it gets installed. <br /> I do not think that the issue is related to using `--ignore-platform-reqs` because in my WIP Composer 2x PR - where Drupal QA is compatible with Composer 2x so I do not need this switch - I am also experiencing the same issue.<br /> <br /> Create a POC zip which hopefully helps to debug this problem.<br /> <br /> ```<br /> $ composer diag<br /> Checking composer.json: OK<br /> Checking platform settings: OK<br /> Checking git settings: OK<br /> Checking http connectivity to packagist: OK<br /> Checking https connectivity to packagist: OK<br /> Checking github.com oauth access: OK<br /> Checking disk free space: OK<br /> Checking pubkeys: FAIL<br /> Missing pubkey for tags verification<br /> Missing pubkey for dev verification<br /> Run composer self-update --update-keys to set them up<br /> Checking composer version: You are not running the latest stable version, run `composer self-update` to update (2.0.0-alpha2 => 1.10.9)<br /> Composer version: 2.0.0-alpha2<br /> PHP version: 7.4.8<br /> PHP binary path: /usr/local/bin/php<br /> OpenSSL version: OpenSSL 1.1.1g 21 Apr 2020<br /> ```<br /> [poc.zip](https://github.com/composer/composer/files/5007326/poc.zip)<br /> [composer install.txt](https://github.com/composer/composer/files/5007323/composer.install.txt)<br /> [composer update.txt](https://github.com/composer/composer/files/5007325/composer.update.txt)<br /> https://github.com/composer/composer/issues/9079#issuecomment-667128919 Fri, 31 Jul 2020 21:48:34 +0800 Re: Error: Could not authenticate against github.com (on GitHub Action) https://github.com/composer/composer/issues/9084#issuecomment-667124552 See https://github.com/shivammathur/setup-php#composer-github-oauth which might help. https://github.com/composer/composer/issues/9084#issuecomment-667124552 Fri, 31 Jul 2020 21:39:11 +0800 Re: Error: Could not authenticate against github.com (on GitHub Action) https://github.com/composer/composer/issues/9084#issuecomment-667123886 I had to enter an oauth token "once" before I could do certain composer actions against github. Try getting a token and going through it without --no-interaction and enter your token. Composer should keep it. Of course, if you are using multiple machines, this becomes onerous "real quick".<br /> https://github.com/composer/composer/issues/9084#issuecomment-667123886 Fri, 31 Jul 2020 21:37:46 +0800