Github 上 composer/composer 的最新 issue 回應 https://github.com/composer/composer/issues Github 上 composer/composer 的最新 issue 回應 en-us Re: Multiple packages in own repository https://github.com/composer/composer/issues/2588#issuecomment-552296868 It would be nice to see this functionality.<br /> <br /> Already it works this way using the `path` repository type. I started to see value in this pattern, and working with it. I found out about the limitation while finally trying to move the system into remote VCS. It seems it's just not going to work this way using VCS, currently.<br /> <br /> I'm wondering the feasibility of creating some kind of hybrid, so that the `VCS` type can scan in a similar way that `path` does, once it's cloned, perhaps with a glob as well... https://github.com/composer/composer/issues/2588#issuecomment-552296868 Mon, 11 Nov 2019 13:18:10 +0800 Re: When does Composer fall back to install a package from packagist.org? https://github.com/composer/composer/issues/8396#issuecomment-552228665 Thank you for your reply! I guess the only way to force Composer to use the repository set in the composer.json file is requiring a specific version. Did I get it right? https://github.com/composer/composer/issues/8396#issuecomment-552228665 Mon, 11 Nov 2019 04:05:30 +0800 Re: Private repositories - unable to clone, only download from dist https://github.com/composer/composer/issues/8402#issuecomment-552217747 What? Is it support?<br /> Where is the support?<br /> <br /> Seems like a hardcoded bug in composer.phar https://github.com/composer/composer/issues/8402#issuecomment-552217747 Mon, 11 Nov 2019 01:57:02 +0800 Re: Transport Exception http/1.1 500 Domain Not Found https://github.com/composer/composer/issues/8422#issuecomment-552213979 This might be a proxy issue on our side as well, but curiously we never get a 500 when using `wget` or `curl`, that are also using the same proxy! https://github.com/composer/composer/issues/8422#issuecomment-552213979 Mon, 11 Nov 2019 01:12:07 +0800 Re: No command can be executed https://github.com/composer/composer/issues/8423#issuecomment-552115526 Conflict with extension:<br /> <br /> > php_screw_plus<br /> <br /> Normal after disabling extension. https://github.com/composer/composer/issues/8423#issuecomment-552115526 Sun, 10 Nov 2019 00:32:01 +0800 Re: Transport Exception http/1.1 500 Domain Not Found https://github.com/composer/composer/issues/8422#issuecomment-552094332 Could this be related to the various network issues fixes, e.g. [composer-patches retry download](https://github.com/cweagans/composer-patches/commit/2e6f72a2ad8d59cd7e2b729f218bf42adb14f590)? https://github.com/composer/composer/issues/8422#issuecomment-552094332 Sat, 09 Nov 2019 20:16:52 +0800 Re: Separate Install & Update code, no longer use vendor dir as input to solver https://github.com/composer/composer/pull/7936#issuecomment-551880561 Considering that I don't want to hold up further work on the 2.0 branch and that the branch is considered unstable anyway I'll merge this PR now and address all the TODOs I added in this PR in separate PRs. Additionally code cleanup any missing tests will also happen on the 2.0 branch then. https://github.com/composer/composer/pull/7936#issuecomment-551880561 Fri, 08 Nov 2019 23:51:03 +0800 Re: Switch to Symfony 3 https://github.com/composer/composer/issues/6552#issuecomment-551868030 I think Composer 2.0 could safely drop support for PHP < 5.6, at the very least. Since even WordPress has been nagging users to upgrade to at least PHP 5.6 for a while now: https://wordpress.org/news/2019/04/minimum-php-version-update/ https://github.com/composer/composer/issues/6552#issuecomment-551868030 Fri, 08 Nov 2019 23:18:43 +0800 Re: Update ClassLoader.php https://github.com/composer/composer/pull/8420#issuecomment-551503653 Sorry but without more explanation as to why this is needed, I don't think we can accept this change.<br /> <br /> Use google translate or something if needed, but we need more infos. The examples make no sense to me. https://github.com/composer/composer/pull/8420#issuecomment-551503653 Fri, 08 Nov 2019 18:06:10 +0800 Re: composer update --no-dev loads dependencies from require-dev key https://github.com/composer/composer/issues/3742#issuecomment-551413867 > It isn't explicitly documented, it's just something that isn't normally done. From an internal perspective as far as the implementation goes it's difficult to handle packages listed in both because the `require-dev` section is consulted to determine which packages are to be removed.<br /> > <br /> > Standard practice in the composer community is that you list your runtime dependencies in `require` and you list your development/test dependencies in `require-dev`. The lock file is normally committed in the repo with the dev dependencies and on deployment it's simply an `install --no-dev`.<br /> > <br /> > Your configuration isn't within the standard use case because your `require-dev` undoubtedly replaces your `require` section. Your scenario may done closer to the norm if you actually had a second `composer.json` with different requires. Such as a `composer-dev.json` and you can call `COMPOSER=composer-dev.json composer update` to get your development dependencies.<br /> > <br /> > Regardless, I do believe there is a bug somewhere and it should at the very least satisfy both constraints.<br /> <br /> Knowing you can have two composer.json files was very helpful. I'm just starting to separate out duplicated and local code into private packages on a dev machine for local (laravel) commands and testing. The --no-dev docs explanation is very confusing. Knowing you can simply have 2 composer files has been very helpful in solving this.<br /> <br /> I would follow up with just adding a few paragraphs to the docs explaining the procedure and how it might be useful for example in a situation where you are developing packages alongside apps. Cheers.<br /> <br /> https://github.com/composer/composer/issues/3742#issuecomment-551413867 Fri, 08 Nov 2019 15:14:13 +0800 Re: Separate Install & Update code, no longer use vendor dir as input to solver https://github.com/composer/composer/pull/7936#issuecomment-551253022 Should probably consider writing a new SolverTest case from scratch since this modified version probably has some pretty nonsensible tests now that installed packages aren't input anymore and that we don't really mark updates or removes, but really just fix packages, ask for them to be installed or expect them to be updated. https://github.com/composer/composer/pull/7936#issuecomment-551253022 Fri, 08 Nov 2019 04:37:19 +0800 Re: composer.json type property became case sensitive in 1.9.1? https://github.com/composer/composer/issues/8411#issuecomment-550979551 Also the name validation is just a warning so I doubt it's breaking your builds.. You should fix it though before it does. https://github.com/composer/composer/issues/8411#issuecomment-550979551 Thu, 07 Nov 2019 16:40:13 +0800 Re: composer.json type property became case sensitive in 1.9.1? https://github.com/composer/composer/issues/8411#issuecomment-550973852 The name field validation was introduced quite a while ago. This issue is regarding the type field validation. Please do not mix up the two of them in the same issue. https://github.com/composer/composer/issues/8411#issuecomment-550973852 Thu, 07 Nov 2019 16:22:10 +0800 Re: Composer won't accept valid responses to user prompt https://github.com/composer/composer/issues/8365#issuecomment-550973190 Because we don't control the contents nor the method of installation. Sometimes other vendors use extra scripts / wrappers which can lead to unexpected issues or behavior. This has happened in the past already. https://github.com/composer/composer/issues/8365#issuecomment-550973190 Thu, 07 Nov 2019 16:20:06 +0800 Re: Composer can not find composer.json file https://github.com/composer/composer/issues/8325#issuecomment-550922346 Ho do you resolve the same error hen using linux, i even changed path to compose location and still getting<br /> 'Composer could not find a composer.json file in /usr/local/bin<br /> To initialize a project, please create a composer.json file as described in the https://getcomposer.org/ "Getting Started" section<br /> ' https://github.com/composer/composer/issues/8325#issuecomment-550922346 Thu, 07 Nov 2019 14:56:47 +0800 Re: composer.json type property became case sensitive in 1.9.1? https://github.com/composer/composer/issues/8411#issuecomment-550398026 Shouldn't this be a breaking change?<br /> <br /> As per 1.9.0 there is a warning:<br /> ```<br /> Deprecation warning: Your package name [...] is invalid, it should have a vendor name, a forward slash, and a package name. The vendor and package name can be words separated by -, . or _. The complete name should match "[a-z0-9]([_.-]?[a-z0-9]+)*/[a-z0-9]([_.-]?[a-z0-9]+)*". Make sure you fix this as Composer 2.0 will error.<br /> ```<br /> <br /> Suddenly all the builds are breaking for no discernible reason.. https://github.com/composer/composer/issues/8411#issuecomment-550398026 Thu, 07 Nov 2019 00:47:46 +0800 Re: composer.json type property became case sensitive in 1.9.1? https://github.com/composer/composer/issues/8411#issuecomment-550375754 Ok, will do. Thanks! https://github.com/composer/composer/issues/8411#issuecomment-550375754 Wed, 06 Nov 2019 23:59:08 +0800 Re: GitHub for repository type git doesn't use setup authentication for https://github.com/acme/private-repository https://github.com/composer/composer/issues/8414#issuecomment-550372811 I think the problem is that it doesn't even get that far because the if before throws the exception if it matches the https url scheme: https://github.com/composer/composer/blob/master/src/Composer/Util/Git.php#L69-L89 https://github.com/composer/composer/issues/8414#issuecomment-550372811 Wed, 06 Nov 2019 23:53:01 +0800 Re: GitHub for repository type git doesn't use setup authentication for https://github.com/acme/private-repository https://github.com/composer/composer/issues/8414#issuecomment-550371258 I was hoping the recent change done at https://github.com/composer/composer/blob/master/src/Composer/Util/Git.php#L99-L118 would fix this.. The idea was that it should try authenticating the commands via this.. but maybe it fails when coming from GitDriver, or due to something else I don't have in mind right now. https://github.com/composer/composer/issues/8414#issuecomment-550371258 Wed, 06 Nov 2019 23:49:36 +0800 Re: GitHub for repository type git doesn't use setup authentication for https://github.com/acme/private-repository https://github.com/composer/composer/issues/8414#issuecomment-550363946 sorry, forgot to add that information. This happens with `Composer version 1.10-dev (1.10-dev+7e929503671fc94de8ba16d665936e63f46d5a56) 2019-11-06 10:27:40` but also latest stable. From what I can see in the git log the GitDriver was last edited 9 months ago. https://github.com/composer/composer/issues/8414#issuecomment-550363946 Wed, 06 Nov 2019 23:33:47 +0800 Re: GitHub for repository type git doesn't use setup authentication for https://github.com/acme/private-repository https://github.com/composer/composer/issues/8414#issuecomment-550361649 can you try with the latest snapshot version (install it with `composer self-update --snapshot`; you can revert to another release channel later using that command again with the right flag) ? @Seldaek made some fixes recently regarding the github/gitlab/bitbucket auth. https://github.com/composer/composer/issues/8414#issuecomment-550361649 Wed, 06 Nov 2019 23:28:49 +0800 Re: composer.json type property became case sensitive in 1.9.1? https://github.com/composer/composer/issues/8411#issuecomment-550356033 Please update to lowercase, and generally speaking I'd say refrain from defining random types like Utilities which have no meaning. The type is meant for installers to know how the package should be installed, and all the known types are lowercased strings following `^[a-z0-9-]+$`. There is really no reason to define the type property otherwise. See https://getcomposer.org/doc/04-schema.md#type https://github.com/composer/composer/issues/8411#issuecomment-550356033 Wed, 06 Nov 2019 23:16:42 +0800 Re: Fix: Add environment variables related to Xdebug to documentation https://github.com/composer/composer/pull/8407#issuecomment-550247480 Thank you, @alcohol and @Seldaek! https://github.com/composer/composer/pull/8407#issuecomment-550247480 Wed, 06 Nov 2019 18:28:12 +0800 Re: Fix: Xdebug vs xdebug https://github.com/composer/composer/pull/8406#issuecomment-550247008 Thank you, @alcohol and @Seldaek! https://github.com/composer/composer/pull/8406#issuecomment-550247008 Wed, 06 Nov 2019 18:26:57 +0800 Re: Fix: Xdebug vs xdebug https://github.com/composer/composer/pull/8406#issuecomment-550246784 Thanks https://github.com/composer/composer/pull/8406#issuecomment-550246784 Wed, 06 Nov 2019 18:26:22 +0800 Re: Add --allow-root option https://github.com/composer/composer/issues/6183#issuecomment-550105292 Thanks so much https://github.com/composer/composer/issues/6183#issuecomment-550105292 Wed, 06 Nov 2019 09:52:40 +0800 Re: Composer won't accept valid responses to user prompt https://github.com/composer/composer/issues/8365#issuecomment-549860344 Isn't the OS packaged installations just a specific version of this repository compiled into an RPM for installation? How do you not support that, other than the timings of upgrades? https://github.com/composer/composer/issues/8365#issuecomment-549860344 Tue, 05 Nov 2019 22:59:45 +0800 Re: Indicate that composer is actually working with `create-project`, instead of appearing unresponsive https://github.com/composer/composer/issues/8409#issuecomment-549716952 > I don't assume things are broken just because I don't get instant feedback.<br /> <br /> I wouldn't call a 90 second delay instant feedback.. <br /> <br /> If I had used Composer prior and not had an experience with a long delay, perhaps this would be a non-issue for me as well. Being new to PHP, I had to provide some additonal extensions to get it working, so it wasn't obvious if it was working. I only noticed due to the network activity while leaving it to run and investigating why it appeared to be unresponsive.<br /> <br /> > We don't really handle requests, unless it involves the word "pull" ;-)<br /> <br /> [Done](https://github.com/composer/composer/pull/8412) ;-)<br /> <br /> > I'm not sure where in the flow and what kind of feedback would improve the UX here, but you seem to have some ideas about that so go ahead<br /> <br /> The initial ~14MB wasn't due to downloading dependencies for laravel, afaik it was downloading some sort of metadata?(something in the `getBestCandidate()` method) Presumably to choose what package version to download.<br /> <br /> I went with a fairly generic message related to the command instead. I am new to PHP, I'm not sure how to add a delay with a boolean toggle so it's only displayed on slow connections, so it'll be one additional line(to what is many anyhow afaik?) for everyone.<br /> <br /> Also moved install directory check prior to the network request so it fails fast(linked related issue). https://github.com/composer/composer/issues/8409#issuecomment-549716952 Tue, 05 Nov 2019 16:31:49 +0800 Re: Indicate that composer is actually working with `create-project`, instead of appearing unresponsive https://github.com/composer/composer/issues/8409#issuecomment-549403952 :man_shrugging: <br /> <br /> I'm not in a position to judge if this needs improving or not since I am biased. I know how the tool works so I know why it can take a while before more meaningful output is generated (when not using verbose output). <br /> <br /> I personally do not like adding output just for the sake of adding output. I'm a patient person and I don't assume things are broken just because I don't get instant feedback. This is of course a personal opinion and we should probably try to aim for what the majority of our users feels is "good".<br /> <br /> > All I'm requesting, is an improvement that shows the composer command has actually began something, that it's running.<br /> <br /> We don't really handle requests, unless it involves the word "pull" ;-)<br /> <br /> Seriously though, submit a pull requests and we'll look it over. I'm not sure where in the flow and what kind of feedback would improve the UX here, but you seem to have some ideas about that so go ahead :+1: https://github.com/composer/composer/issues/8409#issuecomment-549403952 Mon, 04 Nov 2019 23:23:03 +0800 Re: composer.json type property became case sensitive in 1.9.1? https://github.com/composer/composer/issues/8411#issuecomment-549372520 > I don't think that the change was about making this case-sensitive, but about making this following a strict pattern rather than being free-form. Even if we were allowing capital letters in the schema, the change would still render some other values invalid (accents, emojis, etc...)<br /> <br /> Ergo, it is deliberate and I should fix my json conf? https://github.com/composer/composer/issues/8411#issuecomment-549372520 Mon, 04 Nov 2019 22:14:31 +0800