Github 上 composer/composer 的最新 issue 回應 https://github.com/composer/composer/issues Github 上 composer/composer 的最新 issue 回應 en-us Re: curl: (7) Failed to connect to getcomposer.org port 443: Connection refused https://github.com/composer/composer/issues/9047#issuecomment-657454006 It was a network issue. <br /> <br /> I had to modify `/etc/resolv.conf` and add the following lines<br /> <br /> ```<br /> nameserver 8.8.8.8<br /> nameserver 8.8.4.4<br /> ```<br /> <br /> and restart the network. <br /> <br /> Closing issue. https://github.com/composer/composer/issues/9047#issuecomment-657454006 Mon, 13 Jul 2020 17:50:23 +0800 Re: Unexpected change of composer home directory on WSL2 https://github.com/composer/composer/issues/9045#issuecomment-657298334 I was not suggesting any breaking backward incompatible changes. Let me explain in more detail:<br /> <br /> First, this is the algorithm used by Composer now:<br /> <br /> - if COMPOSER_HOME is set, use it<br /> - elseif it's Windows and APPDATA is set, use `%APPDATA%/Composer`<br /> - elseif it's Windows, throw error<br /> - elseif `~/.composer` exists, use it<br /> - elseif XDG_CONFIG_HOME is set, use `$XDG_CONFIG_HOME/composer`<br /> - elseif any of XDG_* variables is set, use `~/.config/composer`<br /> - else use `~/.composer`<br /> <br /> And this is the full algorithm proposed in my previous comment:<br /> <br /> - if COMPOSER_HOME is set, use it<br /> - elseif it's Windows and APPDATA is set, use `%APPDATA%/Composer`<br /> - elseif it's Windows, throw error<br /> - elseif `~/.composer` exists, use it<br /> - elseif XDG_CONFIG_HOME is set, use `$XDG_CONFIG_HOME/composer`<br /> - elseif (any of XDG_* variables is set) or (`~/.config/composer` exists), use `~/.config/composer`   :point_left:<br /> - else use `~/.composer`<br /> <br /> Full compatibility with existing Composer installations on users' machines.<br /> <br /> <hr><br /> <br /> On the other hand, the specification says this:<br /> <br /> > If `$XDG_CONFIG_DIRS` is either not set or empty, a value equal to `/etc/xdg` should be used.<br /> <br /> So I thought perhaps this could be the big clue in XDG detection:<br /> <br /> - if COMPOSER_HOME is set, use it<br /> - elseif it's Windows and APPDATA is set, use `%APPDATA%/Composer`<br /> - elseif it's Windows, throw error<br /> - elseif `~/.composer` exists, use it<br /> - elseif XDG_CONFIG_HOME is set, use `$XDG_CONFIG_HOME/composer`<br /> - elseif (any of XDG_* variables is set) or (`/etc/xdg` exists), use `~/.config/composer`   :point_left:<br /> - else use `~/.composer`<br /> <br /> Full compatibility with existing installations as well.<br /> https://github.com/composer/composer/issues/9045#issuecomment-657298334 Mon, 13 Jul 2020 08:17:07 +0800 Re: GitLab: clarify interactive auth prompt https://github.com/composer/composer/pull/9042#issuecomment-657255067 Not related to this PR, PHP 8 lowest-ignore test fails because [match expression](https://php.watch/versions/8.0/match-expression) is now merged to PHP master. https://github.com/composer/composer/pull/9042#issuecomment-657255067 Mon, 13 Jul 2020 01:55:26 +0800 Re: Unexpected change of composer home directory on WSL2 https://github.com/composer/composer/issues/9045#issuecomment-657206171 > I just hope for something more stable and longterm which seems to be only possible on the Composer's side.<br /> <br /> As already mentioned, the stable and long term solution is to correctly set up your OS using `WSLENV` to set the environment variables you need when running wsl from a Windows native shell, as per the wsl documentation: https://docs.microsoft.com/en-us/windows/wsl/interop<br /> <br /> Otherwise you are asking that some sensible logic (that has been working for over 4 years and which itself took several years to materialize https://github.com/composer/composer/pull/1407) be changed because of your (inadvertent) misconfiguration. https://github.com/composer/composer/issues/9045#issuecomment-657206171 Sun, 12 Jul 2020 18:58:01 +0800 Re: Unexpected change of composer home directory on WSL2 https://github.com/composer/composer/issues/9045#issuecomment-657154072 > It doesn't go back to the xdg location because it already exists at the normal (non-xdg) location.<br /> <br /> This is true, but if it doesn't exist then composer checks `XDG_` variables for location. Whereas my suggestion for composer is to do one additional check for presence of Composer XDG directory in its default location (which is `~/.config/composer`) if all other checks fail.<br /> <br /> From XDG Base Directory Specification:<br /> <br /> > If $XDG_CONFIG_HOME is either **not set** or empty, a default equal to $HOME/.config should be used.<br /> <br /> This is it! However my idea is to use this option only when the directory is already present on disk because I am aware that the very last default option is `~/.composer`.<br /> <br /> > If you need to run stuff across OS boundaries, then `WSLENV` is your friend.<br /> <br /> I just hope for something more stable and longterm which seems to be only possible on the Composer's side. In the meantime the best fix on my part it seems is to do nothing because the composer home directory changes only once ... hopefully :smile: https://github.com/composer/composer/issues/9045#issuecomment-657154072 Sun, 12 Jul 2020 08:33:22 +0800 Re: Composer install or update takes too long https://github.com/composer/composer/issues/7101#issuecomment-657145580 I have been having issues with composer taking a very long time to download json files. I happened to take a look into the json file via my browser to see how long it would take to render and I came across this....<br /> <br /> ![Screenshot 2020-07-12 at 00 16 24](https://user-images.githubusercontent.com/101506/87235569-29812000-c3d5-11ea-9abb-619967e1ef12.png)<br /> <br /> It seems as though people are uploading dvd rip packages?<br /> Also the browser took 1.41 min to load but doing it via composer to install a package took a good 10 mins+ https://github.com/composer/composer/issues/7101#issuecomment-657145580 Sun, 12 Jul 2020 07:19:38 +0800 Re: Unexpected change of composer home directory on WSL2 https://github.com/composer/composer/issues/9045#issuecomment-657137348 It doesn't go back to the xdg location because it already exists at the normal (non-xdg) location.<br /> <br /> If you need to run stuff across OS boundaries, then `WSLENV` is your friend. https://github.com/composer/composer/issues/9045#issuecomment-657137348 Sun, 12 Jul 2020 06:08:18 +0800 Re: Unexpected change of composer home directory on WSL2 https://github.com/composer/composer/issues/9045#issuecomment-657129397 I kind of expected that it was to do with `XDG_` variables. However, as I already mentioned, this `COMPOSER_HOME` change seems to be permanent, i.e. when I get back to Bash, my `COMPOSER_HOME` directory does not get back to its previous location, which makes me think, that Composer relies on `XDG_` variables only if `~/.composer` direcory is not present. So I am thinking maybe composer could also additionally check for existence of `~/.config/composer` if `~/.composer` is not present before moving on to `XDG_` check. Could it be a solution? https://github.com/composer/composer/issues/9045#issuecomment-657129397 Sun, 12 Jul 2020 05:02:36 +0800 Re: Problem with extensions loaded https://github.com/composer/composer/issues/8828#issuecomment-657124769 In my case I had got a public host. Thus I could only upload folders. So what I ve done on localhost was :<br /> 1. type in terminal 'composer install' and then 'composer update -vvv' and get vendor updated<br /> 2. replace hosted vendor folder with new one https://github.com/composer/composer/issues/8828#issuecomment-657124769 Sun, 12 Jul 2020 04:28:56 +0800 Re: Unexpected change of composer home directory on WSL2 https://github.com/composer/composer/issues/9045#issuecomment-657115608 It is not really surprising that this won't work. To explain:<br /> <br /> Composer uses environment variables to determine the composer home directory location: `COMPOSER_HOME` on all platforms, `APPDATA` on Windows, or `HOME` or from `XDG_???` on Unixy.<br /> <br /> The problem with running something in wsl from a Windows native shell is that the environment is not the same as that in the `<distro>` bash shell. Run `env` from bash and `wsl.exe env` from cmd.exe to see the difference.<br /> <br /> What causes this particular scenario is that the `XDG_???` variable is missing from the Windows environment, so Composer assumes that your distro does not use the XDG Base Directory Specifications (which it does, if invoked from the `<distro>` bash shell).<br /> <br /> You can trick this command to work by setting certain environment variables in Windows, but there is no guarantee that all of composer will work. https://github.com/composer/composer/issues/9045#issuecomment-657115608 Sun, 12 Jul 2020 03:21:50 +0800 Re: Packagist suck processing package https://github.com/composer/composer/issues/9044#issuecomment-657024426 🍻 https://github.com/composer/composer/issues/9044#issuecomment-657024426 Sat, 11 Jul 2020 17:31:03 +0800 Re: Packagist suck processing package https://github.com/composer/composer/issues/9044#issuecomment-656991563 This started with an extra high load of updates, and then went on to workers being down during the night which did not help.. Things are catching up slowly now. Should hopefully be back on track soon. https://github.com/composer/composer/issues/9044#issuecomment-656991563 Sat, 11 Jul 2020 13:09:12 +0800 Re: Packagist suck processing package https://github.com/composer/composer/issues/9044#issuecomment-656902700 This seems to be an issue affecting all new packages, actually. All these are in a stuck state:<br /> <br /> <img width="397" alt="image" src="https://user-images.githubusercontent.com/2829600/87204854-dd16e100-c2fd-11ea-9b93-3f35fb0d4a85.png"><br /> https://github.com/composer/composer/issues/9044#issuecomment-656902700 Sat, 11 Jul 2020 05:37:05 +0800 Re: add support for config inheritance https://github.com/composer/composer/pull/4210#issuecomment-656715861 Tok tok 🖖🏻, wondering the same . <br /> Was this stall for any reason?<br /> Is its code still compatible with new Composer's versions?<br /> <br /> Is it potentially merge-able or are there concerns from the core team about this feature? https://github.com/composer/composer/pull/4210#issuecomment-656715861 Fri, 10 Jul 2020 22:49:43 +0800 Re: Composer install or update takes too long https://github.com/composer/composer/issues/7101#issuecomment-656335754 I have the same problem and I have a 150MB connection, it takes up to 20 minutes to update https://github.com/composer/composer/issues/7101#issuecomment-656335754 Fri, 10 Jul 2020 04:29:33 +0800 Re: Composer command not found https://github.com/composer/composer/issues/3625#issuecomment-656237205 try to give executable permission to /usr/local/bin/composer <br /> run this command in terminal : sudo chmod 777 -R /usr/local/bin/composer https://github.com/composer/composer/issues/3625#issuecomment-656237205 Fri, 10 Jul 2020 00:50:21 +0800 Re: PHP support strategy https://github.com/composer/composer/issues/8785#issuecomment-655987677 > if there are multiple versions of PHP installed<br /> <br /> …then you know what you are doing and prepared to deal with consequences.<br /> IMHO https://github.com/composer/composer/issues/8785#issuecomment-655987677 Thu, 09 Jul 2020 16:28:57 +0800 Re: Composer tries/fails to remove PHP extensions when one is listed in "provide" https://github.com/composer/composer/issues/7086#issuecomment-655681388 Alright thanks, closing then. https://github.com/composer/composer/issues/7086#issuecomment-655681388 Thu, 09 Jul 2020 02:24:08 +0800 Re: Composer tries/fails to remove PHP extensions when one is listed in "provide" https://github.com/composer/composer/issues/7086#issuecomment-655573575 Confirmed. Using 2.0 I can no longer reproduce the issue. 👍 https://github.com/composer/composer/issues/7086#issuecomment-655573575 Wed, 08 Jul 2020 22:59:57 +0800 Re: Composer tries/fails to remove PHP extensions when one is listed in "provide" https://github.com/composer/composer/issues/7086#issuecomment-655364895 The fix you linked is not appropriate IMO. This however appears to be fixed in 2.0 already, if you can try and confirm after a `composer self-update --snapshot`. https://github.com/composer/composer/issues/7086#issuecomment-655364895 Wed, 08 Jul 2020 16:14:48 +0800 Re: autoload_real.php on line 69 https://github.com/composer/composer/issues/9037#issuecomment-655302533 The file `app/Utils/helpers.php` is referenced in the `autoload` section of your own `composer.json` file. If it doesn't exist, you will need to adapt your autoload configuration to reflect that (e.g. remove the `files` section). https://github.com/composer/composer/issues/9037#issuecomment-655302533 Wed, 08 Jul 2020 13:52:39 +0800 Re: Composer tries/fails to remove PHP extensions when one is listed in "provide" https://github.com/composer/composer/issues/7086#issuecomment-655147730 Ran into this today, that was a fun issue to debug... Is there any reason why paragonie's fix hasn't been merged? https://github.com/paragonie/composer/commit/47bcdd55b482e2a6dad7097c7f9d6e37a26865f7 If it's just a matter of opening a PR I'd be happy to, just wasn't sure if there was some other reason. https://github.com/composer/composer/issues/7086#issuecomment-655147730 Wed, 08 Jul 2020 05:34:17 +0800 Re: Improvement suggestion for fork with false composer name https://github.com/composer/composer/issues/9036#issuecomment-655068223 Definitely sounds like a good improvement in your use case, but also sounds fairly complex to achieve for such an edge case situation. https://github.com/composer/composer/issues/9036#issuecomment-655068223 Wed, 08 Jul 2020 03:14:56 +0800 Re: [Feature] A package runner (npx like) https://github.com/composer/composer/issues/7272#issuecomment-654868082 @Seldaek In your example, I need to have phpunit already installed in my project for the `composer exec phpunit` command to work.<br /> <br /> I found the idea of running a PHP script interesting without having to install it interesting. https://github.com/composer/composer/issues/7272#issuecomment-654868082 Tue, 07 Jul 2020 21:40:17 +0800 Re: PHP support strategy https://github.com/composer/composer/issues/8785#issuecomment-653935998 > @jhdxr That's not going to be a correct solution if there are multiple versions of PHP installed on the same machine, and only one copy of composer. Any one of them could be used to run self-update.<br /> <br /> If you are running multiple php on the same machine I suppose you should have multiple composer instances as well. just like python+pip vs python3+pip3.<br /> <br /> <br /> https://github.com/composer/composer/issues/8785#issuecomment-653935998 Mon, 06 Jul 2020 04:36:12 +0800 Re: PHP support strategy https://github.com/composer/composer/issues/8785#issuecomment-653850220 @jhdxr That's not going to be a correct solution if there are multiple versions of PHP installed on the same machine, and only one copy of composer. Any one of them could be used to run self-update. https://github.com/composer/composer/issues/8785#issuecomment-653850220 Sun, 05 Jul 2020 14:55:36 +0800 Re: PHP support strategy https://github.com/composer/composer/issues/8785#issuecomment-653843940 @GrahamCampbell I think it's easy to fix. A runtime version check can be added into the installer. https://github.com/composer/composer/issues/8785#issuecomment-653843940 Sun, 05 Jul 2020 13:21:28 +0800 Re: PHP support strategy https://github.com/composer/composer/issues/8785#issuecomment-653814053 With the option to go with dropping older PHP in 2.1, how will someone download the newest version of composer for PHP 5.3. Currently we have `self-update --1` and `self-update --2`, but we are missing a way to say "latest widest compatible version". https://github.com/composer/composer/issues/8785#issuecomment-653814053 Sun, 05 Jul 2020 05:20:11 +0800 Re: Composer slowness when downloading with HTTP https://github.com/composer/composer/issues/8205#issuecomment-653754649 > The workaround I proposed in the issue description seems to be no longer necessary as the execution time is now the same (within a Docker container or not).<br /> <br /> Hi, I am new to community. But this is outstanding issue that still persists. You should have experienced the slowness. I did change the config but the issue still persists. I don't understand why this issue getting closed and got no improvement after years. Similar issues are being asked and getting closed.<br /> <br /> <br /> <br /> https://github.com/composer/composer/issues/8205#issuecomment-653754649 Sat, 04 Jul 2020 19:33:29 +0800 Re: show --tree fatal error https://github.com/composer/composer/issues/9034#issuecomment-653746781 🍻 🚀 https://github.com/composer/composer/issues/9034#issuecomment-653746781 Sat, 04 Jul 2020 18:02:32 +0800