Github 上 composer/composer 的最新 issue 回應 Github 上 composer/composer 的最新 issue 回應 en-us Re: 1.10.13: complex `composer exec` argument parsing fails on Windows The shell used by Github Desktop has no relation to the shell used by PHP for its subprocess (which is `cmd` on Windows) Mon, 28 Sep 2020 17:08:33 +0800 Re: 1.10.13: complex `composer exec` argument parsing fails on Windows Basically I use github desktop app, and it uses "Git bash" with it.<br /> <br /> ![git-shell](<br /> Mon, 28 Sep 2020 16:52:09 +0800 Re: 1.10.13: complex `composer exec` argument parsing fails on Windows @saas786 could provide some details on your environment? Mon, 28 Sep 2020 15:32:48 +0800 Re: 1.10.13: complex `composer exec` argument parsing fails on Windows What terminal are you using on Windows? `src/Plugin.php; if [ $? -eq 1 ]; then exit 0; fi` is a bash command. Mon, 28 Sep 2020 05:07:25 +0800 Re: Ecosystem Upgrade: Composer Plugin Readiness for 2.0 Hi,<br /> <br /> I think `` 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. Mon, 28 Sep 2020 00:34:31 +0800 Re: Access error fixed. Accessing private properties from within the same file is perfectly valid.<br /> <br /> Seems your IDE is wrong Sun, 27 Sep 2020 21:24:07 +0800 Re: Access error fixed. 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 /> Sun, 27 Sep 2020 20:59:56 +0800 Re: Access error fixed. Which access errors does this PR fix? How to reproduce? Sun, 27 Sep 2020 14:26:26 +0800 Re: Composer hangs in "Something's changed, looking at all rules again" state 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 🤷‍♀️. Sun, 27 Sep 2020 04:57:34 +0800 Re: Previously (potentially) invalid version strings now valid I have verified that this is a bug recently introduced in composer/semver, and opened a PR there<br /> <br /> Sat, 26 Sep 2020 21:11:59 +0800 Re: Previously (potentially) invalid version strings now valid 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 /> 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 This stack trace shows that the error happens in the `symfony/flex` plugin. And this is already tracked at Sat, 26 Sep 2020 04:06:22 +0800 Re: Previously (potentially) invalid version strings now valid 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 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. Sat, 26 Sep 2020 01:10:42 +0800 Re: Previously (potentially) invalid version strings now valid see Sat, 26 Sep 2020 01:01:19 +0800 Re: Previously (potentially) invalid version strings now valid You should use one of `^3.0`, `3.*` and not combination of both. Sat, 26 Sep 2020 00:34:11 +0800 Re: Composer hangs in "Something's changed, looking at all rules again" state 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? Fri, 25 Sep 2020 16:47:15 +0800 Re: [Idea] Reducing versions entering the SAT solver by identifying useless ones I might have an idea on how to fix this, though. I'll keep trying :) Fri, 25 Sep 2020 15:14:16 +0800 Re: [v2] Reached invalid decision id 0 while looking through :) Fri, 25 Sep 2020 03:15:13 +0800 Re: composer remove is not equivalent to manually editing composer.json and running composer update Well described issue. It is a duplicate of<br /><br /><br /> <br /> and there is a pull request to fix it<br /> Fri, 25 Sep 2020 02:15:18 +0800 Re: Specify APCu autoloader prefix But it's in the right milestone, it won't get forgotten Thu, 24 Sep 2020 23:05:04 +0800 Re: Specify APCu autoloader prefix Just free time to review one last time. Thu, 24 Sep 2020 23:04:42 +0800 Re: Specify APCu autoloader prefix @Seldaek anything else needed? Thu, 24 Sep 2020 22:23:32 +0800 Re: [Idea] Reducing versions entering the SAT solver by identifying useless ones 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`. Thu, 24 Sep 2020 21:24:12 +0800 Re: All messages are sent to stderr It's correct, as explained in 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. Thu, 24 Sep 2020 20:26:53 +0800 Re: All messages are sent to stderr ![image](<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. Thu, 24 Sep 2020 18:53:33 +0800 Re: It is recommended to store development dependencies and production dependencies in separate directories. See - and sorry but no we are not going to change this. Thu, 24 Sep 2020 17:24:05 +0800 Re: [v2] Reached invalid decision id 0 while looking through Confirm:<br /> <br /> 1. Source code:<br /> 1. Failing build:<br /> <br /> Downgrading to v1 fixes the issue Thu, 24 Sep 2020 13:51:25 +0800 Re: Fatal error: Allowed memory size of 1073741824 bytes exhausted 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** Wed, 23 Sep 2020 21:42:14 +0800 Re: It is recommended to store development dependencies and production dependencies in separate directories. 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. Wed, 23 Sep 2020 18:54:54 +0800 Re: Observation: platform-check (composer 2) > 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 /> Wed, 23 Sep 2020 14:37:10 +0800