-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
[Process] Fix backwards compatibility for invalid commands #58189
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
||
// Backwards compatibility. To be removed in version 8.0 | ||
if (!\is_resource($process) && \is_array($commandline)) { | ||
$process = @proc_open($this->buildShellCommandline($commandline), $descriptors, $this->processPipes->pipes, $this->cwd, $envPairs, $this->options); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we trigger a deprecation here like this?
if (\is_resource($process)) {
trigger_deprecation('symfony/process', '7.1', 'Executing non-existent commands will no longer start the process and instead throw a "%s" exception in 8.0.', ProcessStartFailedException::class);
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or just document it in the UPGRADE-7.1.md?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there's nothing to do IMHO, just revert to the previous behavior
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We lose a great deal of performance for cases where proc_open()
fails. That’s why I’d prefer to remove this in a future version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We lose a great deal of performance for cases where proc_open() fails
Sure but do we have a use case where failures are on the hot path?
If not, things are fine as is. If yes, we should make this opt-in.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’m not sure. If someone has that use case they could probably make a pull request then.
I’d still like the behavior better that an invalid command throws an exception (like an invalid cwd already does). This would be the better API design I think. But that’s your decision of course :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Forward plan looks fine to me. We are tightly bound by BC concerns :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we want to throw again an exception on invalid command in 8.0, we need to provide an opt-in in 7.x (but not 7.1 as new deprecations cannot be introduced in patch versions) with a deprecation when you keep using the old error handling behavior. We cannot just change the behavior in 8.0.
1941795
to
e13bf4e
Compare
Thank you @ausi. |
As discussed in #57946 (comment)