Christophe Coevoet

When you package is the root package, the behavior is indeed different that when using it as a dependency. That's totally expected (that's the difference between `require-dev` and `require`)

To me, this does not belong to composer. A blue-green deployment is not only concerned about the `vendor` folder, but also about the application code. and once that enters into...

The new PoolOptimizer in Composer indeed covers the performance benefits of this for the most part.

@bensebborn please run `sha384sum /tmp/composer`. If this file is indeed the installer, the checksum should be `906a84df04cea2aa72f40b5f787e49f22d4c2f19492ac310e8cba5b96ac8b64115ac402c8cd292b8a03482574915d1a8`

https://github.com/bamarni/composer-bin-plugin has a slight difference (not counting the fact that it manages things with separate composer.json and composer.lock by wrapping normal composer executions in those folders): the tools it installs...

@Ocramius that's true for https://github.com/bamarni/composer-bin-plugin indeed. But the proposal of @nicolas-grekas allows (and enforces) to share address space between a tool section and the app (but not between multiple tool...

> which is for when the tool does autoload your code in which case you want the dependencies to be resolved. But I wonder, isn't that problem completely artificial? How...

> * Composer being able to skip download/copy of same dependencies multiple times (I have yet to seen any solution which avoids duplicating all of those files) the download part...

> Why not just apply this format to `require` and `require-dev` sections? that would be a BC break for the ecosystem > After all, anything in the vendor directory can...

@Chi-teck the structure of the composer.json (to add sections inside `require`) cannot change. That's why this issue suggests a new section