Github 上 composer/composer 的最新 issue 回應 Github 上 composer/composer 的最新 issue 回應 en-us Re: Cleanup of old compression algo @stof I tried applying the same diff algo to require/... - it doesn't help much, after gzip is done with the file it's hardly noticeable so I think it's best to leave it as is to avoid even more complexity and chance of bugs. Wed, 20 Feb 2019 18:12:03 +0800 Re: WIP: Write php-based caches which is faster and saves loads of memory Alright thanks for the update Wed, 20 Feb 2019 17:25:22 +0800 Re: WIP: Write php-based caches which is faster and saves loads of memory Thx for coming back to this proposal.<br /> <br /> To be honest I also had problems to reproduce the benefits the intial protoype suggested.<br /> In the meanwhile I got the feeling that the measurable improvements I observed were actually a bug in blackfire.<br /> <br /> I have tried using this similar approach in another lib and stopped pursuing it after getting this very same results.<br /> <br /> I suggest closing it for now. Wed, 20 Feb 2019 16:44:03 +0800 Re: WIP: Write php-based caches which is faster and saves loads of memory @staabm I brought this up to speed with latest 2.0 at Seldaek/php-cache ( I can't reproduce your findings though. <br /> <br /> Running a `composer update --dry-run --profile` in a loop on a symfony project I see no relevant improvement in either memory usage or runtime length. Granted this isn't using blackfire, but still I'd expect to see at least runtime improvement. The memory one I am not sure if it's just due to the way blackfire reports it or not. Because I guess the memory is still used, but it might be allocated by opcache and not the php process itself, so it appears to be using less?<br /> <br /> I'd be glad if you can give it a go again and share your findings.. Or if anyone else has time to try it out from my fork. Wed, 20 Feb 2019 16:30:19 +0800 Re: [RFC] Split releases and dev branches in separate provider files in composer repositories See and Wed, 20 Feb 2019 16:25:29 +0800 Re: Fix type issues Thanks for literally everything you do! Wed, 20 Feb 2019 01:38:18 +0800 Re: Fix type issues Alright thanks for the overview :)<br /> <br /> Wed, 20 Feb 2019 01:09:58 +0800 Re: Fix type issues You're welcome! Let me know if you have any questions - I understand the pain of having two competing configs. Some great projects use both, [some great projects use none](<br /> <br /> YMMV, but there's not much to differentiate Psalm and PHPStan when the type coverage is relatively low (81% for the `src` directory). There only real difference that'll matter to you if/when you attempt to "level up" is configuration - Psalm allows you to pick and choose what issues you care about (and in which files) because we need that level of granularity at Vimeo, whereas PHPStan is a more one-size-fits-all sort of deal. Wed, 20 Feb 2019 01:03:53 +0800 Re: Fix type issues Alright, thanks for the updates. I think we might look at Psalm again in the future, maybe with v3 once we can drop old PHP versions and add much more type info inline it'll make it easier to adopt multiple static analyzers. Tue, 19 Feb 2019 22:35:23 +0800 Re: add gitlab-dist-format option Closing as it's replaced by Tue, 19 Feb 2019 18:50:26 +0800 Re: "tar" type repository does not allow .tar.bz2 archives Closing as it's replaced by Tue, 19 Feb 2019 18:49:59 +0800 Re: Trigger an error on composer install without a lock file Works for me but IMO we should print a warning and if interactive ask user if they `... want to run update instead now? [Yn]`. No point in making the user type it out themselves.. Tue, 19 Feb 2019 18:26:58 +0800 Re: Fix type issues I am not sure what to do here.. Skimming through changes I spotted a few which are incorrect, which makes me think I'd have to go through all of them in depth before merging. There are definitely some correct ones too though so closing outright isn't good either.<br /> <br /> Why are some nullables switched to `?foo` while others are `foo|null`? I believe the latter is preferred as some tooling doesn't support `?foo` in phpdoc.<br /> <br /> Adding Psalm to the build I'd rather not as it'll probably be quite redundant with PHPStan if we increase the check level there. It's also one more error-exclusion list to maintain. Tue, 19 Feb 2019 17:41:54 +0800 Re: PHP 7.3 breaks composer with continue/targeting error (solution: downgrade to 7.2) For me Same error occured as:<br /> <br /> > [ErrorException] "continue" targeting switch is equivalent to "break". Did you mean to use " continue 2"?<br /> <br /> and what i have done is **downloaded the latest composer from the official site and now it is working fine** so there is not any fault of PHP 7.3. And downgrading to PHP 7.2 is not the solution. it is giving error because of old version of composer and if you are troubling with the same issue try to upgrading the composer first and see if it works for you. Mon, 18 Feb 2019 21:38:03 +0800 Re: post-install-cmd not working on vendor dependency Right, alternatively you could write a plugin package I suppose. Mon, 18 Feb 2019 21:28:52 +0800 Re: Incorrect resolution of repository during outdated I am not sure - but given we are changing a ton of how that works in v2, I think I'd rather close this for now and if it ever crops up again on v2 we can have a closer look. Mon, 18 Feb 2019 21:28:21 +0800 Re: Enforce valid package names in name/require/require-dev/provide/replace/conflict/suggest Should consider #7975 before moving ahead here. Mon, 18 Feb 2019 21:21:57 +0800 Re: Add PHPStan @Seldaek Try to install with lowest deps, and also install phpstan-shim, not full phpstan package with all dependencies. Mon, 18 Feb 2019 20:57:29 +0800 Re: Add PHPStan I'd say that level 5 is reasonable for every project - that's the level that starts checking types of arguments passed to functions and methods.<br /> <br /> Level 6 and 7 are really strict and only for greenfield projects I'd say - they're much more strict about unions and nullables and the main problem is that they find issues in stuff that's usually only in developer's heads but not expressed in code - for example if phpDoc says `Foo|Bar` but you know it's always `Foo`, PHPStan on L6 will tell you "be careful, it might be Bar". Same thing with L7 - if your phpDoc or native typehint says that something might be `|null` but you know it isn't, PHPStan will still complain. Mon, 18 Feb 2019 20:46:27 +0800 Re: Add PHPStan Yes of course, the plan is to increase the level slowly as long as it yields sensible output. I don't really want to fight with a tool about nitpicks otherwise it becomes a negative return on investment, so we will see where the right level is. Mon, 18 Feb 2019 20:43:23 +0800 Re: Add PHPStan Sounds that's it :) BTW let me know if you need any help with this - I'd love to see the PHPStan level increased, basically on level 0 it just looks for static errors and for existing methods called on `$this` - it's much more capable on higher levels :) Mon, 18 Feb 2019 20:41:17 +0800 Re: Add PHPStan Hmm I guess the problem is I have phpstan installed in composer's global dir - which has a few of the latest symfony/* packages installed in there, so probably that means phpstan finds the missing classes in there.<br /> <br /> I tried running it with phpstan installed as shim locally and that works, so will add back those exclusions to make the build pass I guess. Mon, 18 Feb 2019 20:37:18 +0800 Re: Add PHPStan Looks like the build isn't entirely deterministic/repetable. You probably have different dependency versions installed locally? Mon, 18 Feb 2019 20:30:12 +0800 Re: Add PHPStan Thanks - build failed though in a strange way<br /> <br /> If I add back those two lines in config.neon to fix the travis build:<br /> <br /> ```<br /> - '~^Instantiated class Symfony\\Component\\Console\\Terminal not found\.$~'<br /> - '~^Class Symfony\\Component\\Console\\Input\\StreamableInputInterface not found\.$~'<br /> ```<br /> <br /> I get this error locally:<br /> <br /> ```<br /> $ phpstan analyse src tests --configuration=phpstan/config.neon --autoload-file=phpstan/autoload.php<br /> 356/356 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓] 100%<br /> <br /> --------------------------------------------<br /> Error<br /> --------------------------------------------<br /> Ignored error pattern ~^Instantiated class Symfony\\Component\\Console\\Terminal not found\.$~ was not matched in reported errors.<br /> Ignored error pattern ~^Class Symfony\\Component\\Console\\Input\\StreamableInputInterface not found\.$~ was not matched in reported errors.<br /> --------------------------------------------<br /> <br /> [ERROR] Found 2 errors<br /> ```<br /> <br /> Any ideas? Mon, 18 Feb 2019 20:27:58 +0800 Re: [Composer\Downloader\TransportException] The "" file could not be downloaded: I also faced this problem inside the campus. Campus internet network blocked some dns. I changed my network, basically, connect to the internet with my phone via hotspot, it worked. Mon, 18 Feb 2019 20:05:16 +0800 Re: Composer hangs on install > Composer version 1.2.2<br /> <br /> That's a joke right?<br /> <br /> Try running a version that is still actively maintained :sweat_smile: Mon, 18 Feb 2019 15:31:25 +0800 Re: Composer hangs on install Seeing similar behavior with the following environment.<br /> Composer version 1.2.2<br /> PHP 7.0.33-0+deb9u1<br /> Running composer install -vvv<br /> Hangs at<br /> Resolving dependencies through SAT Mon, 18 Feb 2019 12:28:13 +0800 Re: composer global require considered harm^H^H^H occasionally inconvenient and confusing >I am -1 on using PHP-Scoper / PHP-Parser in Composer due to the limitations described in the comment above. I am +1 on seeing PHP-Scoper, or equivalent function thereof, becoming a standard language feature in a future version of PHP. Under that scenario, then supporting it in a dependency manager or installer would be natural.<br /> <br /> Just to make sure there is no confusion: I suggested a way in which it could make it slightly easier (publishing the scoped content as an artefact - it doesn't have any dependence on the tool used to achieve it neither is there any promise that the code is perfectly scoped either) but the responsibility to scope a library/application is entirely on the maintainer(s). Mon, 18 Feb 2019 03:21:31 +0800 Re: composer global require considered harm^H^H^H occasionally inconvenient and confusing I agree that it is a problem that Composer is doing double-duty as both a dependency manager and an installer. Other languages, such as Go, do these options with separate tools. The PHP community doesn't have a uniform installer. `composer global require` looks like such a thing, which is why so many people continue to use it. Lacking an installer provided by the PHP project itself, a safe and sanctioned way to do this in Composer 2 is important, and I am glad to see thought going into moving in this direction.<br /> <br /> I am -1 on using PHP-Scoper / PHP-Parser in Composer due to the limitations described in the comment above. I am +1 on seeing PHP-Scoper, or equivalent function thereof, becoming a standard language feature in a future version of PHP. Under that scenario, then supporting it in a dependency manager or installer would be natural. Mon, 18 Feb 2019 02:39:07 +0800 Re: composer global require considered harm^H^H^H occasionally inconvenient and confusing >1 - What is the purpose of requiring a package "globally" rather than locally in a project?<br /> >* For _Composer plugins_ it's the only way to modify the behaviour of commands like composer init or composer install before project specific plugins are installed.<br /> <br /> It has been my usage thus far. The best example is `hirak/prestissimo`.<br /> <br /> >* For _PHP tools/binaries_ the goal is make a single installation available across projects.<br /> >* Personally I think this is entirely unnecessary. The only thing you're saving with shared tools is a little bit of disk space<br /> <br /> I don't necessarily think the need here is to save a bit of disk space but rather but some commands/tools globally usable. For example:<br /> <br /> ```<br /> $ composer global require psy/psysh<br /> # Provided you exported the global Composer bins to your PATH:<br /> $ psysh<br /> ```<br /> <br /> That said I agree the current implementation/usage is limited.<br /> <br /> <hr /><br /> <br /> Before extending on the potential solutions, I would like add another angle to the problem.<br /> <br /> The root of the issue is that Composer is being used as a tool installer in some cases, because it's convenient and we don't have anything better. For example you cannot have `brew install deptrac` or `apt-get install deptrac`, even if `deptrac` is meant to be used as a standalone tool. Indeed even though the application deptrac could be downloadable as a PHAR, you will have the issue of:<br /> <br /> - Making sure the PHAR can be executed: it's just a compressed PHP file so it still needs PHP. And so far there is no way to export a PHAR bundled with a static PHP binary (and even in this case you could still be limited by some extensions required)<br /> - Making sure the PHAR is runnable: the right PHP version, the right extensions<br /> - Making sure the PHAR is legitimate: if it's coming from GitHub, making sure it's downloaded via HTTPs will be enough for most of the time, an extra security step is to GPG sign the artefact and register your signature elsewhere and have a check. Some tools like [phive]( offers this.<br /> - Updating the PHAR. Right now there is no good out-of-the box self-update command (there is some packages, but mostly unmaintained & not complete/secure enough IMO). So updating the PHAR itself is a bit inconvenient unless using a tool like [phive](<br /> - Keeping a PHAR version<br /> <br /> And regardless of how the application is installed, via Composer or as a PHAR, as mentioned above, there is an issue whenever the application will load/execute arbitrary code as there is a risk of conflicts.<br /> <br /> <hr/><br /> <br /> In light of the above and @naderman analysis of the issue. I think a `require-tool` option would solve the installation issue. Be it for globally or on a project basis, what I would really love from this option is that it accepts both a regular Composer package and a PHAR:<br /> <br /> - When given a library, that it installs the library in a dedicated repository. This way no matter how many tools you install, no matter what their dependencies are, there will never be any conflict with it. My current best to go-to alternative for this right now is [bamarni/composer-bin-plugin](, and I think it could be a good base to this.<br /> - When installing a PHAR, it would simply download the PHAR. An existing alternative solution is [tommy-muehle/composer-tool-installer-plugin]( <br /> - The current plugin however does not handle version constraints which is a bit of a shame. Maybe with the `require-tool`, a possible solution would be to give the regular composer package name & version constraint, but setting an option "phar" and it would download the PHAR over the package (e.g. by expecting the PHAR to be in the release besides the code source).<br /> - Another concern is when one wishes to go an extra step security wise and GPG sign his PHAR. In this case, maybe a similar approach to phive could be picked. Actually phive has a [composer plugin]( as well which could be used as a base.<br /> <br /> IMO this solution would elegantly solve the issue of installing tools/apps via Composer whilst being able to keeping track of them on a project level when desired.<br /> <br /> <hr/><br /> <br /> Now regarding the last issue of code conflict. I think indeed [Humbug PHP-Scoper]( is the way to go (disclaimer: I am the maintainer of the tool). It is in my opinion not perfect, mostly because:<br /> <br /> - It is not battle tested on thousands of projects. That said I've been using it extensively for a lot of projects nonetheless and it works relatively well. It's however bound to have some lingering bugs (like all tools I guess).<br /> - It is heavily dependent on [PHP-Parser]( which means if PHP-Parser is lagging behind in a PHP version support so will PHP-Scoper.<br /> - As a consequence of the point above, PHP-Parser is _very slow_. It's heavy AST manipulation. While there is tricks to make it go faster (e.g. leveraging parallelism or being smarter about what is scoped like done in [Box](, it is and will always be way to slow for allowing a on the fly package scoping integrating in the package manager like you can see for example in JavaScript with yarn or npm.<br /> - Because PHP is what it is as a language, there will _always_ be edge cases that PHP-Scoper will not be able to take care of itself. A non exhaustive list of examples:<br /> - A dynamic reference to a class name, e.g. `$x = 'MyClass'.$foo.'Handler;` or `$x = preg_replace('/Foo/', 'Acme', Bar::class);`<br /> - Exotic usage of autoloading mechanism e.g. like done in some [Hoa projects]( (IIRC [hoaproject/Consistency]( in peculiar)<br /> - Referencing functions relying on the autoloading fallback, i.e.:<br /> <br /> ```php<br /> namespace Acme;<br /> <br /> tap(); // is it \tap() or \Acme\tap()?<br /> ```<br /> - Relying on some unorthodox ways to configure your PHP application, like the Symfony YAML/XML configuration files (actually PHP-Scoper has a way to deal with is but it's a solution specifically developed for Symfony, not a generic way to tackle the issue)<br /> <br /> PHP-Scoper offers a number of ways to overcome those limitations and you will always find a way to make it work regardless of how dirty the code is, but my point is unlike you have a very traditional standard code, it will most likely never achieve the experience of "it works" on the first try. I'm trying very hard to make it as easy as possible, but this is how the language and its limitations are.<br /> <br /> All of this to say I don't think PHP-Scoper or any similar tool will ever be robust and reliable enough to scope packages on the fly natively by Composer. However one is definitely encourage to use to it:<br /> <br /> - Scope a library code and publish it, for example like [PHPStan]( did with [PHPStan shim](<br /> - Scope the PHAR like done for PHP-Scoper itself or [Box](<br /> <br /> <hr/><br /> <br /> I think another topic which needs to be discussed is the choice regarding the PHARs. Indeed at least in the solution I've mentioned above, we are talking of having a good integration for PHAR files with Composer.<br /> <br /> Maybe another approach would be to completely forget about PHARs. If composer can install those tools as libraries, maybe it could install the shims instead. I.e. instead of having:<br /> <br /> - `acme/foo` published as a package<br /> - scoped PHAR provided for `acme/foo` in each release<br /> <br /> or:<br /> <br /> - `acme/foo` published as a package<br /> - `acme/foo-shim` (scoped version of `acme/foo`) published as a regular Composer package<br /> <br /> The scoped code could be uploaded as an artefact with the release and Composer would have a way to understand "this is a shim package, i.e. a code without conflict, pick this one for `require-tool`".<br /> <br /> Indeed right now having a scoped PHAR or a separate a shim packages are both non-trivial amount of work for each maintainers. Publishing the shim package as an artefact still requires the work of making the scoping work, but would remove the burden to deal with PHARs or having a shim package to synchronize.<br /> <br /> <br /> Mon, 18 Feb 2019 02:17:40 +0800