Closed soren121 closed 2 years ago
I'll note that Foxy's behavior has always been wrong here-- the docblock for that Composer method has always specified that timeout should be an integer. It's only breaking now because Composer is enforcing that.
I feel like the fix here is to simply not call Composer\Util\ProcessExecutor::setTimeout()
if "manager-timeout" is null, thereby keeping Composer's default timeout in place. I can submit a PR for this if that sounds okay.
The timeout could be null
because the ProcessExecutor class uses the Symfony Process component whose timeout may be null
, cf. the constructor of the Process class and that the property was not Typed. It was therefore reasonable to consider the PHP doc as incomplete, which often happens, and not as a deliberate choice of the developers.
Now that the property is Typed, it is therefore necessary to use the constant PHP_INT_MAX
to obtain a pseudo equivalent to an unlimited timeout. The method Foxy\Config\Config::get()
has a second argument to set a default value.
And any contribution is welcome :-)
Foxy's documentation describes the "manager-timeout" config option as being a nullable integer, with the default being null. In Composer 2.3, the ProcessExecutor class has been updated, and its setTimeout method now requires an int value for the timeout parameter. This makes Foxy's default configuration incompatible with Composer 2.3+.
Here's the stack trace thrown when using the default configuration with Composer 2.3:
A workaround for now is to set a non-null "manager-timeout" value in your composer.json ("300" is the default in Composer):