STDERR and STDOUT do not seem to be properly separated in the symfony console output
As per findings in #76, the STDERR and STDOUT get mixed with each other regardless what we do.
This is likely an effect of combining the composer/composer CLI output with the symfony/console output, which is probably not a scenario that symfony/console was designed for.
Ref: https://github.com/Roave/BackwardCompatibilityCheck/pull/76#discussion_r191179996
FYI, I briefly experimented with: copying a composer.phar into the checked out project and running the phar, instead of running the composer installer php class directly. this seemed far faster for some reason and good for memory consumption.
@bendavies that's because composer.phar runs without GC, but here we want to have an explicit dependency on the version (since we rely on it), and speed isn't a big blocker.
Ah yes, gc. Do you mean you want to control the composer version? You could bundle a phar?
Composer is already an extremely good and stable distribution system, so I'm not going to invent something new 😜
On Mon, 4 Jun 2018, 19:50 Ben Davies, [email protected] wrote:
Ah yes, gc. Do you mean you want to control the composer version? You could bundle a phar?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Roave/BackwardCompatibilityCheck/issues/79#issuecomment-394441552, or mute the thread https://github.com/notifications/unsubscribe-auth/AAJakP8tUdiSJUYq6mrNJJ8I2SKn3w8rks5t5XOAgaJpZM4UZU4d .
I'm not sure what you mean :) I was suggesting including a controlled composer phar in this project and using it to install project deps :)
I was suggesting including a controlled composer phar in this project and using it to install project deps :)
This is "distribution". No btw, not going to include a third-party phar in releases