Allow for custom PHP binary

[jissereitsma]

The current approach is using the php binary as the one to be used for running bin/magento amongst other things. In some situations, the php default binary might be pointing to say PHP 5.6, while the /usr/bin/php7.2 should be used instead. Perhaps, there could be a check for an environment variable PHP=/usr/bin/php7.2 to bypass this issue.

This is a tricky one and I am not sure if we ever are going to be able to successfully do this in an automated fashion. Currently it uses /usr/bin/env php.

Based on a suggestion by Anton we probably should do some minimal comparison. Ie if /usr/bin/env php is 5.6 on M2.3 install we should fail.

I think we should definitely start by adding an extra optional parameter --php_binary that will override /usr/bin/env php.

Anyone knows how to best detect the current needed / running version of php?

It doesn't look like composer.lock holds this information. And just running php -v may be incorrect (in my current example one has to know it is is /usr/local/php70/bin/php-cli and php -v would be 7.4). Best I can come up with so far is create a temporary phpinfo file, open the web/secure/base_url via curl or something to then read out the php version. Less than ideal.

[jissereitsma]

I'm a little bit lost on the context and lack the time to dive into this, but here is some cents: If I create a sample script test.php with the following contents:

#!/usr/bin/env php
<?php echo phpversion()."\n";

I can chmod the script to 755 and execute it directly: ./test.php (so without prepending php to it). This works, because in my environment, the php is executable in the shell. Executing which php shows for me PHP 7.3 (which is located in /usr/bin/php).

Now I've got another binary /usr/bin/php7.4 (and 7.1 and 7.2 for that matter). To execute the same script with PHP 7.4, I can simply run /usr/bin/php7.4 ./test.php. So overriding the env reference could be done simply by appending the PHP version. Couldn't be done here? (Again, I'm tired and didn't bother to dive into the context.)

@jissereitsma Thanks for chiming in. I am currently grappling with the inverse (in other words I am not the one who is setting up the server).

Ideally we would be able to run some command and that will spit out /usr/bin/php7.2 or whatever is currently serving the site in an unknown environment.

We can now override the php binary via command line input --php-bin="/usr/bin/env php".

Next steps I think could be to run a version comparison of the php binary and what is in vendor/magento/magento2-base/composer.json as a check.

One idea to investigate would be to parse the history of the shell and then grab whatever is in front of the last bin/magento command as presumably someone was using it prior.