Github 上 composer/composer 的最新 issue 回應 https://github.com/composer/composer/issues Github 上 composer/composer 的最新 issue 回應 en-us Re: 1.10.13: complex `composer exec` argument parsing fails on Windows https://github.com/composer/composer/issues/9244#issuecomment-699882310 The shell used by Github Desktop has no relation to the shell used by PHP for its subprocess (which is `cmd` on Windows) https://github.com/composer/composer/issues/9244#issuecomment-699882310 Mon, 28 Sep 2020 17:08:33 +0800 Re: 1.10.13: complex `composer exec` argument parsing fails on Windows https://github.com/composer/composer/issues/9244#issuecomment-699873533 Basically I use github desktop app, and it uses "Git bash" with it.<br /> <br /> ![git-shell](https://user-images.githubusercontent.com/1642796/94411231-c3b16280-0191-11eb-8dbb-55cfb9665cf4.jpg)<br /> https://github.com/composer/composer/issues/9244#issuecomment-699873533 Mon, 28 Sep 2020 16:52:09 +0800 Re: 1.10.13: complex `composer exec` argument parsing fails on Windows https://github.com/composer/composer/issues/9244#issuecomment-699833982 @saas786 could provide some details on your environment? https://github.com/composer/composer/issues/9244#issuecomment-699833982 Mon, 28 Sep 2020 15:32:48 +0800 Re: 1.10.13: complex `composer exec` argument parsing fails on Windows https://github.com/composer/composer/issues/9244#issuecomment-699688272 What terminal are you using on Windows? `src/Plugin.php; if [ $? -eq 1 ]; then exit 0; fi` is a bash command. https://github.com/composer/composer/issues/9244#issuecomment-699688272 Mon, 28 Sep 2020 05:07:25 +0800 Re: Ecosystem Upgrade: Composer Plugin Readiness for 2.0 https://github.com/composer/composer/issues/8726#issuecomment-699657360 Hi,<br /> <br /> I think `UPGRADE-2.0.md` should explain how locking/updating/installing has changed in Composer 2.<br /> I've noticed across a few plugins that developers not fully aware of the rather drastic change in how Composer operates. Roughly speaking:<br /> <br /> - Composer v1: Composer resolves dependencies (dispatching `*_DEPENDENCIES_SOLVING`), iterates packages (while dispatching `PRE_PACKAGE_*` before `PRE_FILE_DOWNLOAD`), then finally writes the lock file.<br /> - Composer v2: Composer resolves dependencies (dispatching `PRE_POOL_CREATE`), writes the lock file, dispatches `PRE_OPERATIONS_EXEC`, downloads the packages (while dispatching `PRE_FILE_DOWNLOAD`), then iterates packages (while dispatching `PRE_PACKAGE_*`).<br /> <br /> In particular, people are assuming that `PRE_OPERATIONS_EXEC` is a replacement for `PRE_DEPENDENCIES_SOLVING` since they are dispatched in a similar-looking routine. The closest event to the latter would actually be `PRE_POOL_CREATE`.<br /> <br /> Thanks,<br /> <br /> ---<br /> <br /> [2020-09-28] I've updated my breakdown to include the new events in v2. https://github.com/composer/composer/issues/8726#issuecomment-699657360 Mon, 28 Sep 2020 00:34:31 +0800 Re: Access error fixed. https://github.com/composer/composer/pull/9247#issuecomment-699635270 Accessing private properties from within the same file is perfectly valid.<br /> <br /> Seems your IDE is wrong https://github.com/composer/composer/pull/9247#issuecomment-699635270 Sun, 27 Sep 2020 21:24:07 +0800 Re: Access error fixed. https://github.com/composer/composer/pull/9247#issuecomment-699632472 ClassLoader is being referenced for variables "$prefixLengthsPsr4", "$prefixDirsPsr4", "$prefixesPsr0", "$classMap". Cannot see if it is, because the variable is "private" defined as. This fixes it from showing the error.<br /> <br /> In addition :<br /> https://i.hizliresim.com/k4LeMV.png https://github.com/composer/composer/pull/9247#issuecomment-699632472 Sun, 27 Sep 2020 20:59:56 +0800 Re: Access error fixed. https://github.com/composer/composer/pull/9247#issuecomment-699592432 Which access errors does this PR fix? How to reproduce? https://github.com/composer/composer/pull/9247#issuecomment-699592432 Sun, 27 Sep 2020 14:26:26 +0800 Re: Composer hangs in "Something's changed, looking at all rules again" state https://github.com/composer/composer/issues/7665#issuecomment-699547029 I had this same issue in a package requiring `illuminate/database:^6.0` plus another upstream package. I had to manually inspect all the deps to find the issue: Another package required `carbon/carbon:^1.0` but `illuminate/database` requires `carbon/carbon:^2.0`.<br /> <br /> Not sure why this made Composer fall over, it wasn't a spectacularly complicated dependency graph 🤷‍♀️. https://github.com/composer/composer/issues/7665#issuecomment-699547029 Sun, 27 Sep 2020 04:57:34 +0800 Re: Previously (potentially) invalid version strings now valid https://github.com/composer/composer/issues/9246#issuecomment-699494022 I have verified that this is a bug recently introduced in composer/semver, and opened a PR there https://github.com/composer/semver/pull/117<br /> <br /> https://github.com/composer/composer/issues/9246#issuecomment-699494022 Sat, 26 Sep 2020 21:11:59 +0800 Re: Previously (potentially) invalid version strings now valid https://github.com/composer/composer/issues/9246#issuecomment-699142583 And the docs that you linked to mention<br /> <br /> > For this reason, Composer throws an error and says that this is invalid.<br /> <br /> Composer no longer throws an error and says that this is invalid.. so I think this is definitely a new bug.<br /> https://github.com/composer/composer/issues/9246#issuecomment-699142583 Sat, 26 Sep 2020 04:35:25 +0800 Re: Argument 1 passed to Composer\Semver\Intervals::compactConstraint() must implement interface Composer\Semver\Constraint\ConstraintInterface, string given https://github.com/composer/composer/issues/9245#issuecomment-699129723 This stack trace shows that the error happens in the `symfony/flex` plugin. And this is already tracked at https://github.com/symfony/flex/issues/678 https://github.com/composer/composer/issues/9245#issuecomment-699129723 Sat, 26 Sep 2020 04:06:22 +0800 Re: Previously (potentially) invalid version strings now valid https://github.com/composer/composer/issues/9246#issuecomment-699047162 I think you are misreading my report. We're aware that wildcards are a bad idea. And that combining those is an error.<br /> <br /> The issue is that *old versions* of projects used those wildcards, and prior to the recent changes, those weird versions *used to fail validation*, and our packages.drupal.org repository would reject them. Now that we've upgraded the validator on p.d.o to use the most recent version, versions like `^3.*` are now passing validiation, being delivered in the metadata, which breaks older composer clients. <br /> <br /> So, *should they still fail validation* ? Presumably the linked issues were to make validation more strict and keep garbage out of the metadata, so I dont think we want to also loosen validation at the same time. https://github.com/composer/composer/issues/9246#issuecomment-699047162 Sat, 26 Sep 2020 01:10:42 +0800 Re: Previously (potentially) invalid version strings now valid https://github.com/composer/composer/issues/9246#issuecomment-699042405 see https://getcomposer.org/doc/faqs/why-are-version-constraints-combining-comparisons-and-wildcards-a-bad-idea.md https://github.com/composer/composer/issues/9246#issuecomment-699042405 Sat, 26 Sep 2020 01:01:19 +0800 Re: Previously (potentially) invalid version strings now valid https://github.com/composer/composer/issues/9246#issuecomment-699029258 You should use one of `^3.0`, `3.*` and not combination of both. https://github.com/composer/composer/issues/9246#issuecomment-699029258 Sat, 26 Sep 2020 00:34:11 +0800 Re: Composer hangs in "Something's changed, looking at all rules again" state https://github.com/composer/composer/issues/7665#issuecomment-698806674 Same error here:<br /> `Something's changed, looking at all rules again (pass #88)` loads forever <br /> <br /> I read through the whole issue - is there no way to see what rule 88 actually is? https://github.com/composer/composer/issues/7665#issuecomment-698806674 Fri, 25 Sep 2020 16:47:15 +0800 Re: [Idea] Reducing versions entering the SAT solver by identifying useless ones https://github.com/composer/composer/issues/8287#issuecomment-698765333 I might have an idea on how to fix this, though. I'll keep trying :) https://github.com/composer/composer/issues/8287#issuecomment-698765333 Fri, 25 Sep 2020 15:14:16 +0800 Re: [v2] Reached invalid decision id 0 while looking through https://github.com/composer/composer/issues/9012#issuecomment-698536513 :) https://github.com/composer/composer/issues/9012#issuecomment-698536513 Fri, 25 Sep 2020 03:15:13 +0800 Re: composer remove is not equivalent to manually editing composer.json and running composer update https://github.com/composer/composer/issues/9243#issuecomment-698505816 Well described issue. It is a duplicate of<br /> https://github.com/composer/composer/issues/8870<br /> https://github.com/composer/composer/issues/9218<br /> <br /> and there is a pull request to fix it<br /> https://github.com/composer/composer/pull/9223 https://github.com/composer/composer/issues/9243#issuecomment-698505816 Fri, 25 Sep 2020 02:15:18 +0800 Re: Specify APCu autoloader prefix https://github.com/composer/composer/pull/9212#issuecomment-698404070 But it's in the right milestone, it won't get forgotten https://github.com/composer/composer/pull/9212#issuecomment-698404070 Thu, 24 Sep 2020 23:05:04 +0800 Re: Specify APCu autoloader prefix https://github.com/composer/composer/pull/9212#issuecomment-698403889 Just free time to review one last time. https://github.com/composer/composer/pull/9212#issuecomment-698403889 Thu, 24 Sep 2020 23:04:42 +0800 Re: Specify APCu autoloader prefix https://github.com/composer/composer/pull/9212#issuecomment-698378055 @Seldaek anything else needed? https://github.com/composer/composer/pull/9212#issuecomment-698378055 Thu, 24 Sep 2020 22:23:32 +0800 Re: [Idea] Reducing versions entering the SAT solver by identifying useless ones https://github.com/composer/composer/issues/8287#issuecomment-698341753 I've actually had this idea a while ago too but never investigated it more. I now did and the issue here is the following.<br /> Imagine `package/name` in versions<br /> <br /> * `1.0.0`<br /> * `1.0.1`<br /> * `1.0.2`<br /> * `1.1.0`<br /> * `2.0.0`<br /> <br /> It's perfectly possible for them to have exactly the same definitions of `require`, `provide`, `conflict` and `replace` (which is what makes up the same definition imho).<br /> <br /> This then is a problem because the optimization step would remove all of them except `2.0.0` (when not `--prefer-lowest`) but that's an issue because other dependencies may require `package/name` in e.g. `^1.1`. https://github.com/composer/composer/issues/8287#issuecomment-698341753 Thu, 24 Sep 2020 21:24:12 +0800 Re: All messages are sent to stderr https://github.com/composer/composer/issues/3795#issuecomment-698311321 It's correct, as explained in https://github.com/composer/composer/issues/3795#issuecomment-204893057. Azure is wrong here for calling it 'errors' instead of "lines of diagnostic output".<br /> <br /> You should rely on return values for success/failure detection, not lines of output. Azure does, that's why it says succeeded. Why do you care about this *bug in Azure* that it confuses "log output" with "errors"? Like uhm, it counts lines, so it would also report a single error with 9 lines of explanation as 10 errors. https://github.com/composer/composer/issues/3795#issuecomment-698311321 Thu, 24 Sep 2020 20:26:53 +0800 Re: All messages are sent to stderr https://github.com/composer/composer/issues/3795#issuecomment-698270077 ![image](https://user-images.githubusercontent.com/50120314/94135918-6dc47e00-fe64-11ea-8cbb-a4ee38058643.png)<br /> <br /> This is an automated release pipeline on Azure DevOps, which is compatible with a wide number of build/package management tools etc. I have seen many pipelines, this one with composer is the only one which logs errors even when there are no actual failures to report. It just logs on STDERR that it successfully installed some packages!<br /> <br /> This must be considered as a composer bug, there's no other explanation for it, it should be reopened and fixed. https://github.com/composer/composer/issues/3795#issuecomment-698270077 Thu, 24 Sep 2020 18:53:33 +0800 Re: It is recommended to store development dependencies and production dependencies in separate directories. https://github.com/composer/composer/issues/9238#issuecomment-698227561 See https://getcomposer.org/doc/faqs/should-i-commit-the-dependencies-in-my-vendor-directory.md - and sorry but no we are not going to change this. https://github.com/composer/composer/issues/9238#issuecomment-698227561 Thu, 24 Sep 2020 17:24:05 +0800 Re: [v2] Reached invalid decision id 0 while looking through https://github.com/composer/composer/issues/9012#issuecomment-698128305 Confirm:<br /> <br /> 1. Source code: https://github.com/Slamdunk/storageless/tree/ca88182a71c23945dbbcdc264c7ee7975f456ea9<br /> 1. Failing build: https://github.com/Slamdunk/storageless/runs/1155304146<br /> <br /> Downgrading to v1 fixes the issue https://github.com/composer/composer/issues/9012#issuecomment-698128305 Thu, 24 Sep 2020 13:51:25 +0800 Re: Fatal error: Allowed memory size of 1073741824 bytes exhausted https://github.com/composer/composer/issues/4373#issuecomment-697374273 I had the same issue on windows > wampp server.<br /> **Solution: <br /> Step 1) change memory_limit =-1 <br /> Step 2) check your php version on cli (php -v) and set the system environment variables path according to your php version** https://github.com/composer/composer/issues/4373#issuecomment-697374273 Wed, 23 Sep 2020 21:42:14 +0800 Re: It is recommended to store development dependencies and production dependencies in separate directories. https://github.com/composer/composer/issues/9238#issuecomment-697288427 I also wonder.<br /> This is the first time I ever hear about this, and it sure doesn't seem to be the case for the PHP (and composer) ecosystem.<br /> Especially since the tool properly handles the separation on the low level and does not include dev dep on prod systems by design<br /> Separating them in different folders is not helping here either.<br /> And committing vendor seems also like a huge smell and counter productive to me given the whole picture of how composer works and was designed to work. https://github.com/composer/composer/issues/9238#issuecomment-697288427 Wed, 23 Sep 2020 18:54:54 +0800 Re: Observation: platform-check (composer 2) https://github.com/composer/composer/issues/9222#issuecomment-697164793 > Composer already supports disabling that platform check, either at the project level or globally on the system (if you don't run the `composer install` command in your prod server but on another system, _that_ system is the one where the global config could be useful).<br /> <br /> Thanks for the explanation. Because it is a project descision involving multiple programmers/systems not to perform the platform requirements check, the way to go for me is to use the composer.json flag.<br /> <br /> > This platform-check features comes from the fact that a common mistake is to use incompatible dependencies (when composer is not run on the production server so `composer install` is not itself reporting the issue) and then get errors which don't clearly explain the problem and often get reported to the package using a new PHP syntax, while this package has no issue. This creates a lot of issue triaging work for many open-source project, and this `platform-check` feature solves that. <br /> <br /> Again thanks for the explanation, it is now clearer what problem the platform requirements check tries to solve. But as I observed there is a downside to this solution.<br /> <br /> I have hesitations about the solution. If open source projects get a lot of issues because of platform requirements failing, how is this solution going to solve that?<br /> * The developer, working on a local environment, very early gets a black site when platform requirements are failing. But a new platform requirement might not be noticed, because the developer already activated too much extensions. Or a platform requirement was already needed for a ```--dev``` package. When the developer environment gets black, that's not really an issue because it only affects one person and not production.<br /> * The production site, after FTP deployment, goes black because platform requirements are failing. The developer didn't notice a new plaform requirement and the production site has as less as possible extensions activated because of security. Here the production site goes down, affecting many persons. And that's where my grey scenario gets in to play.<br /> <br /> <br /> <br /> >Also, depending on the architecture of the project, disabling might still not allow things to work (so the grey scenario would not actually be grey) and for such case, it only increases the time until the actual issue is known.<br /> <br /> That depends, it could be the grey scenario equals the black scenario, but could also be a grey scenario. The answer depends on each individual situation. In the grey scenario, at least there is a chance some parts are working, and the remaining parts can incrementally be made working. In the black scenario for sure none part is working. And in the black scenario logging will not work, because the autoloading of logging will fail. And composer does not have a logging facility. No logging really is a problem.<br /> <br /> > This feature is not built for an utopia world. In an utopia world, local, staging and production environments are identical and so there is no issue regarding not respecting platform requirements.<br /> <br /> I agree with this conclusion, as you have explained the problem to be solved is the number of issues in open-source projects. Which apparently is a real life problem.<br /> https://github.com/composer/composer/issues/9222#issuecomment-697164793 Wed, 23 Sep 2020 14:37:10 +0800