Validate PHP version to be used by the Composer process calls

If it's core-post-mvp, shouldn't we remove the sprint tag? 🤔

1. @Gábor Hojtsy mentioned in chat

   I think the PHP platform setting is an interesting idea, unless you have composer plugins that need PHP 8.x itself and will choke on trying to run on PHP 7 (or other version variants as applicable in the future).

   This is a good point. If we wanted to get real complicated we could make sure that no allowed plugins, which I think would be the only packages that would have PHP code that will run during composer commands, don't have php requirement that is incompatible with version PHP that is actually used for the process.

2. #4 removed the sprint tag.

   If we wanted to do something for MVP I think the minimum we could do would be add a validation error if 2 php versions were not exactly the same. But of course that might start to cause failures because we might have been missing the fact the 2 versions of php might have been different for some sites but does not cause any problems. Maybe because the php version were in the same major or patch version

3. One thing that would make this situation better if \PhpTuf\ComposerStager\Domain\Exception\RuntimeException gave us access to the actual process so we could output a more trimmed version of the error. @Wim Leers do you make an issue for this problem?

   I think that would allow up to trim the error in the issue summary down to just what is after "Error Output" so it would be

   Loading composer repositories with package information Info from https://repo.packagist.org: #StandWithUkraine Updating dependencies Your requirements could not be resolved to an installable set of packages. Problem 1 - symfony/finder v6.2.5 requires php >=8.1 -> your php version (7.4.33) does not satisfy that requirement. - drush/drush 11.4.0 requires symfony/finder ^4.0 || ^5 || ^6 -> satisfiable by symfony/finder[v6.2.5]. - drush/drush is locked to version 11.4.0 and an update of this package was not requested.

   I think this would slightly better for end user because there is not quite as much to get through before you see the actual problem. it won't be as nice a specific validator for this problem but it would have the benefit of helping any composer error.

Adding to sprint because people are running of issues. A lot of other issue are interdependent.

updated the suggested solution

OK, so, I don't think we should we doing this as proposed. I have a better idea. 😈

Rather than meekly ask Composer which PHP version it's going to use, we can and should just force it to use the same runtime the web server is.

Try this at the terminal: php $(which composer) --version. You can just have PHP directly execute the Composer phar, rather than have it to try to just start in the nearest available PHP runtime.

So, in ProcessFactory, IMHO what we should do here is, if we're trying to execute a Composer command (we have a method for that), detect the path to the current PHP runtime (there is a constant, PHP_BINARY, or PHP_BINDIR, which will work for that), and prefix the command string with the path to the PHP executable. Boom. No need for validation: it will just always use the one we want.

Assigning to @tedbow to validate this approach before Omkar implements it.

I chatted with @phenaproxima about. while I agree his solution could be an improvement, it also seems possible that it *could* break some sites. Probably a low probability but also we can't be sure the solution would even solve the original problem on 🐛 Automatic Updates hosting test result on Siteground Active . It is likely @gabor doesn't have access to this site anymore since it was just for testing. So it seem too risky for now to put in a solution for problem that was only reported 1x and we can't actually confirm it will fix that problem

Postponing for now. We need to figure how to test this on real host that has this problem

Postponing for now. We need to figure how to test this on real host that has this problem

Shouldn't we not postpone this issue and instead do the necessary investigation here? 😅

#11 yes you are right. We need to investigate more.

Assigning to @phenaproxima update the summary with different proposed solution