Github 上 composer/composer 的最新 issue 回應 https://github.com/composer/composer/issues Github 上 composer/composer 的最新 issue 回應 en-us Re: Composer hangs in "Something's changed, looking at all rules again" state https://github.com/composer/composer/issues/7665#issuecomment-590029221 I have changed "pdepend/pdepend" version from 2.2.2 to 2.4.0<br /> <br /> "require-dev": {<br /> "lusitanian/oauth": "~0.3 <=0.7.0",<br /> "pdepend/pdepend": "2.2.2",<br /> "phpmd/phpmd": "@stable",<br /> "sebastian/phpcpd": "~3.0.0",<br /> "squizlabs/php_codesniffer": "1.5.3"<br /> }<br /> <br /> to<br /> <br /> "require-dev": {<br /> "lusitanian/oauth": "~0.3 <=0.7.0",<br /> "pdepend/pdepend": "2.4.0",<br /> "phpmd/phpmd": "@stable",<br /> "sebastian/phpcpd": "~3.0.0",<br /> "squizlabs/php_codesniffer": "1.5.3"<br /> }<br /> <br /> It works for me https://github.com/composer/composer/issues/7665#issuecomment-590029221 Sun, 23 Feb 2020 13:30:25 +0800 Re: Memory limit Exhausted https://github.com/composer/composer/issues/8063#issuecomment-589999469 I have 16 GB Ram - 6 in use, so 9-10 GB free. Nonetheless I get this error at 1405091840 bytes.<br /> I run composer with memory_limit=-1 https://github.com/composer/composer/issues/8063#issuecomment-589999469 Sun, 23 Feb 2020 05:21:38 +0800 Re: Invalid lockfile after modifying composer.json with plugin https://github.com/composer/composer/issues/8606#issuecomment-589836809 I guess this is a feature request then: as an end user, when I run `composer create-project`, I'd like some way to bake the minimum supported PHP version into my composer.json file, so that other people who clone my new project with newer PHP versions don't break my dependencies. Seems like a CLI parameter would be best if a plugin can't do it. Let me know if you want me to close this and open a new issue. https://github.com/composer/composer/issues/8606#issuecomment-589836809 Sat, 22 Feb 2020 05:12:03 +0800 Re: Leftover dependency after upgrading package https://github.com/composer/composer/issues/8633#issuecomment-589787712 @stof I would start working on this issue if you said what and when we need to automate.<br /> https://github.com/composer/composer/issues/8633#issuecomment-589787712 Sat, 22 Feb 2020 02:56:54 +0800 Re: `composer outdated` calls isAbandoned on my PHP-generated package extending Package class https://github.com/composer/composer/issues/8638#issuecomment-589783948 Thanks!!<br /> Maybe you could tame those codes. https://github.com/composer/composer/issues/8638#issuecomment-589783948 Sat, 22 Feb 2020 02:47:51 +0800 Re: `composer outdated` calls isAbandoned on my PHP-generated package extending Package class https://github.com/composer/composer/issues/8638#issuecomment-589782494 Some code seems to expect all packages to be CompletePackage instances... https://github.com/composer/composer/issues/8638#issuecomment-589782494 Sat, 22 Feb 2020 02:43:58 +0800 Re: Using YAML for configuration? https://github.com/composer/composer/issues/440#issuecomment-589720111 Please don't send a pull request, and please everyone stop wasting everyone<br /> else's time here.<br /> <br /> On Fri, 21 Feb 2020, 16:38 Colan Schwartz, <notifications@github.com> wrote:<br /> <br /> > I don't see any linked pull requests on this issue. If this is really<br /> > important for folks, create one. If the code is there (say adding support<br /> > for YAML as well as JSON), the maintainers would be much more likely to<br /> > merge it. If you're not interested in doing the work, or paying someone<br /> > else to do it, please stop complaining.<br /> ><br /> > —<br /> > You are receiving this because you were mentioned.<br /> > Reply to this email directly, view it on GitHub<br /> > <https://github.com/composer/composer/issues/440?email_source=notifications&email_token=AABM27SGY23F76UUJWKKTI3RD7YOTA5CNFSM4AASMCQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMTDJGY#issuecomment-589706395>,<br /> > or unsubscribe<br /> > <https://github.com/notifications/unsubscribe-auth/AABM27Q2UEUT7SSPMXIJXPLRD7YOTANCNFSM4AASMCQA><br /> > .<br /> ><br /> https://github.com/composer/composer/issues/440#issuecomment-589720111 Sat, 22 Feb 2020 00:09:40 +0800 Re: Using YAML for configuration? https://github.com/composer/composer/issues/440#issuecomment-589706395 I don't see any linked pull requests on this issue. If this is really important for folks, create one. If the code is there (say adding support for YAML as well as JSON), the maintainers would be much more likely to merge it. If you're not interested in doing the work, or paying someone else to do it, please stop complaining. https://github.com/composer/composer/issues/440#issuecomment-589706395 Fri, 21 Feb 2020 23:38:15 +0800 Re: Composer can not find composer.json file https://github.com/composer/composer/issues/8325#issuecomment-589529452 same here.<br /> ![Capture](https://user-images.githubusercontent.com/61148495/75012432-8cb8f700-54b4-11ea-8647-01854a9ae753.PNG)<br /> <br /> # composer update<br /> Composer could not find a composer.json file in /mnt/c/container/24template/6748-MY/app/local<br /> To initialize a project, please create a composer.json file as described in the <br /> https://getcomposer.org/ "Getting Started" section<br /> <br /> OS Build 1964.1005 https://github.com/composer/composer/issues/8325#issuecomment-589529452 Fri, 21 Feb 2020 15:16:06 +0800 Re: Allow more finegrained control over what caches to clear https://github.com/composer/composer/pull/8349#issuecomment-589299057 Excellent idea!<br /> <br /> Short version:<br /> - `~/.cache/composer` is huge, but per-package cache is small<br /> - `cache clear` sometimes solves inconsistent cache states that lead to confusing errors. The ability to **selectively** clear per-package cache allows users to **quickly** confirm (or invalidate) a possible source for a bug they would experience.<br /> <br /> Long version:<br /> <br /> My personal use-case is the following: I deploy various feature-branches of a PHP project in different environments (database, filesystem). `Docker containers` are used for virtualization and `composer` for PHP dependencies' deployment.<br /> <br /> It scales quite well but only because I share `composer`'s cache across various the runs. But this has also been **the** weak point of my setup from the beginning.<br /> Not only parallel containers runs (_= parallel runs of `composer require` of different branches of the same project_) resulted in (hard-to-track) race-conditions and inconsistent cache states, but even when running the (dockerized) composer commands (almost) sequentially was the cache state still frequently problematic.<br /> <br /> I took the habit of clearing the 70 MB of cache (related to my PHP project) in order to workaround this issue while still keeping the other >600MB living inside `~/.composer/cache`.<br /> <br /> But there are two paths involved:<br /> - `.composer/cache/vcs/git-gitlab.com-xxxx-foo-bar.git/` (notice the `HEAD` file)<br /> - `.composer/cache/repo/gitlab.com/xxx/foo/bar`<br /> <br /> Having a way to clear the cache without doing manual package-name interpolation externally would greatly improve the situation. https://github.com/composer/composer/pull/8349#issuecomment-589299057 Fri, 21 Feb 2020 04:43:32 +0800 Re: Leftover dependency after upgrading package https://github.com/composer/composer/issues/8633#issuecomment-589242832 I would keep the issue opened, because that's something that should be fixed automatically for the case of unneeded packages IMO https://github.com/composer/composer/issues/8633#issuecomment-589242832 Fri, 21 Feb 2020 02:35:23 +0800 Re: Leftover dependency after upgrading package https://github.com/composer/composer/issues/8633#issuecomment-589224834 Tested it and it worked. It's still confusing and once you have the leftover dependency it's hard to understand what's going on, but it works correctly with the appropriate flag. https://github.com/composer/composer/issues/8633#issuecomment-589224834 Fri, 21 Feb 2020 01:55:09 +0800 Re: Leftover dependency after upgrading package https://github.com/composer/composer/issues/8633#issuecomment-589219891 I think yes. https://github.com/composer/composer/issues/8633#issuecomment-589219891 Fri, 21 Feb 2020 01:43:10 +0800 Re: SHA1 sum of package dists should be more reliable than a SHA1 on the zip result https://github.com/composer/composer/issues/2540#issuecomment-589218523 > But I guess Packagist has to clone the repo anyway<br /> <br /> No it does not. For github repos, the GithubDriver extracts all data from the API. https://github.com/composer/composer/issues/2540#issuecomment-589218523 Fri, 21 Feb 2020 01:40:09 +0800 Re: Leftover dependency after upgrading package https://github.com/composer/composer/issues/8633#issuecomment-589216052 So I just had to run it with some flags and it would work? <br /> ```<br /> composer require --dev codeception/codeception:^4.1 --update-with-dependencies<br /> ```<br /> https://github.com/composer/composer/issues/8633#issuecomment-589216052 Fri, 21 Feb 2020 01:34:32 +0800 Re: Invalid lockfile after modifying composer.json with plugin https://github.com/composer/composer/issues/8606#issuecomment-589215892 well, the thing is, we don't want to let plugins modify the composer.json between the time the solver runs and the time the hash is generated. The whole point of that hash is to check whether the composer.lock contains dependencies which correspond to the output of the solver for that composer.json. In your case, running an update with the changes applied would install different dependencies. so the lock file is indeed outdated. https://github.com/composer/composer/issues/8606#issuecomment-589215892 Fri, 21 Feb 2020 01:34:14 +0800 Re: Leftover dependency after upgrading package https://github.com/composer/composer/issues/8633#issuecomment-589212070 well, that's probably because when you updated `codeception`, you did not allow composer to modify existing packages being dependencies of this package, and so it kept it requested at its locked version.<br /> <br /> @naderman maybe that's something that could be solved more easily in v2 (ensuring that a `remove` command does not keep unused dependencies around).<br /> <br /> https://github.com/composer/composer/issues/8633#issuecomment-589212070 Fri, 21 Feb 2020 01:25:54 +0800 Re: [2.0][RFC] Stop normalizing dev-master as 9999999-dev https://github.com/composer/composer/issues/8323#issuecomment-589208482 the effect of that change would be similar to my previous comment, but it is probably the simplest way to implement it. https://github.com/composer/composer/issues/8323#issuecomment-589208482 Fri, 21 Feb 2020 01:18:42 +0800 Re: [2.0][RFC] Stop normalizing dev-master as 9999999-dev https://github.com/composer/composer/issues/8323#issuecomment-589208117 An idea that I just got for that: stop *normalizing* the default branch (`master` or `trunk`) to `9999999-dev`, so that their normalized version stays `dev-master` (not comparable by semver and so not matching `conflict: > 5`). And instead, consider that this default branch has a branch alias of `9999999-dev` if there is no explicit branch alias. https://github.com/composer/composer/issues/8323#issuecomment-589208117 Fri, 21 Feb 2020 01:17:52 +0800 Re: Include the current progress when installing or updating packages https://github.com/composer/composer/issues/6932#issuecomment-589021254 What about a --progress flag? I am dealing with a `composer global update` that has currently run for ages without any updates. Would be helpful to see if it's stuck somewhere. https://github.com/composer/composer/issues/6932#issuecomment-589021254 Thu, 20 Feb 2020 21:25:40 +0800 Re: All messages are sent to stderr https://github.com/composer/composer/issues/3795#issuecomment-588341691 Noticed this in my docker build. For quick and simple reference for redirection to stdout:<br /> ```<br /> <command> 2>&1<br /> ```<br /> i.e.<br /> ```<br /> composer require foo/bar 2>&1<br /> ``` https://github.com/composer/composer/issues/3795#issuecomment-588341691 Thu, 20 Feb 2020 01:26:56 +0800 Re: allow php 8 for nightly testing https://github.com/composer/composer/pull/8618#issuecomment-588235608 > I wanted to test them for satis but since it depends on composer/composer and that still requires 7.x only :-(<br /> <br /> You can simply run composer with the ignore platform reqs flag? https://github.com/composer/composer/pull/8618#issuecomment-588235608 Wed, 19 Feb 2020 21:40:45 +0800 Re: Wasted space with .git folder in defined repositories https://github.com/composer/composer/issues/7058#issuecomment-588162369 I understand that the git folder is downloaded during the install.<br /> But why issnt it enough when the .git folder goes to the `cache-repo-dir` ?<br /> It should be possible to keep installtype as `source` or `auto` but tell composer that the `.git` dir should only be in `cache-repo-dir` but not in the project or vendir directory.<br /> <br /> This .git folder in the vendor or target directory is yust space-wasting for `library` but it is a real problem for custom installer types like [ProcessWire-Module][pw-installer].<br /> In that case you have the `.git` folder in your install directory for the module, and that is a real problem.<br /> <br /> And I think it is no good solution to yust `.gitignore` all this folders.<br /> For some custom installer types it could break the main-system when there are subfolders from git what dont belong to the installed composer-package.<br /> <br /> [pw-installer]: https://github.com/harikt/pwmoduleinstaller https://github.com/composer/composer/issues/7058#issuecomment-588162369 Wed, 19 Feb 2020 18:59:12 +0800 Re: Parse error: syntax error, unexpected '' (T_ENCAPSED_AND_WHITESPACE), expecting end of file in ../vendor/composer/autoload_namespaces.php on line 14 https://github.com/composer/composer/issues/8608#issuecomment-588126196 Downgraded to VirtualBox 5.2.36 and issue is gone, very confusing since only composer seems to be affected by this. https://github.com/composer/composer/issues/8608#issuecomment-588126196 Wed, 19 Feb 2020 17:40:20 +0800 Re: Writing an Envato (Theme Forest) installer/plugin https://github.com/composer/composer/issues/8623#issuecomment-587597166 Thank you @stof !<br /> <br /> We have [the first release](https://packagist.org/packages/szepeviktor/composer-envato). https://github.com/composer/composer/issues/8623#issuecomment-587597166 Wed, 19 Feb 2020 02:07:58 +0800 Re: Writing an Envato (Theme Forest) installer/plugin https://github.com/composer/composer/issues/8623#issuecomment-587592187 Custom installers are not able to provide repository data, as they are called *after* resolving dependencies.<br /> <br /> What you would need to provide is probably a custom type of repository, registered by a plugin. You can look at https://github.com/fxpio/composer-asset-plugin to see how this was done by this plugin.<br /> You might still need a custom installer if you want to wait until download time to generate the URL due to expiration.<br /> <br /> Note that a plugin wanting to provide repository data **must** be installed globally. Requiring it locally will not work when you run a composer install or update without already having a populated vendor folder, as you would not have the repository data when running the solver. https://github.com/composer/composer/issues/8623#issuecomment-587592187 Wed, 19 Feb 2020 01:57:05 +0800 Re: Delete initialization of unused variable in solver https://github.com/composer/composer/pull/8612#issuecomment-587566944 Indeed, these were left over from some old code that has since been deleted. https://github.com/composer/composer/pull/8612#issuecomment-587566944 Wed, 19 Feb 2020 01:03:24 +0800 Re: Vendor name in composer init command https://github.com/composer/composer/issues/8620#issuecomment-587464267 It's just your username, and it is shown as a default value. You can provide it with whatever value you want. https://github.com/composer/composer/issues/8620#issuecomment-587464267 Tue, 18 Feb 2020 21:38:58 +0800 Re: Parse error: syntax error, unexpected '' (T_ENCAPSED_AND_WHITESPACE), expecting end of file in ../vendor/composer/autoload_namespaces.php on line 14 https://github.com/composer/composer/issues/8608#issuecomment-587463674 VirtualBox is known to cause filesystem issues or issues that relate to the filesystem in general. Avoid using synced directories between host and VM. But even just inside the VM it can be a bit of a hit and miss scenario. https://github.com/composer/composer/issues/8608#issuecomment-587463674 Tue, 18 Feb 2020 21:37:34 +0800 Re: allow php 8 for nightly testing https://github.com/composer/composer/pull/8618#issuecomment-587462654 I wanted to test them for `satis` but since it depends on `composer/composer` and that still requires 7.x only :-( https://github.com/composer/composer/pull/8618#issuecomment-587462654 Tue, 18 Feb 2020 21:35:13 +0800