Installation fails due to specifying an absolute path: '/usr/bin/php'

[Viveur]

Current Behaviour

MCrypt Extension is loaded as part of MAMP's PHP (phpinfo.php confirms this).

MAMP's version of PHP is specified in my $path

Running 'which php -v' returns MAMP's version of PHP.

However as Magento's installer calls /usr/bin/php it forces the use of OS X's built-in version of PHP which does not have the extension loaded.

/usr/bin/php -f '/Users/me/Documents/DATA/WWW/magento2/dev/shell/maintenance.php' -- --set='1' 2>&1

This results in the error:

[ERROR] exception 'Exception' with message 'exception 'Exception' with message 'Module 'Magento_Core' depends on 'mcrypt' PHP extension that is not loaded.' in /Users/[name]/Documents/WWW/magento2/lib/internal/Magento/Framework/Module/DependencyManager.php:56

Suggested Behaviour

Install script should possibly use the the system's preferred version of PHP rather than specifying an absolute path.

[maksek]

Hi @bit32, you are describing very specific configuration for OS X, looks like you have 2 versions on php installed. You may remove your /usr/bin/php and make symlink to MAMP php in /usr/bin/. Or install the same extensions for your default installation of php. If you will use macports, there is php_select port, which do the same - replacing /usr/bin/php with your preferred.
We going to consider possible solutions how to make installer universal to different systems, but we are focusing on supported OS. If you have possible universal solution - feel free to contribute and publish pull request.

[Viveur]

Sure, thanks.

I just mentioned it as MAMP is fairly popular and that error hasn't been mentioned before.

Totally understand that you are focused on getting other things working first tho.

[Vinai]

It is quite common to have PHP installed in a location different from /usr/bin/php.
The common approach I see (and have used) is to call
/usr/bin/env php -finstead of calling php directly.

[buskamuza]

We actually don't hard-code path to PHP, so it's not always /usr/bin/php. We're searching for PHP executable using \Symfony\Component\Process\PhpExecutableFinder::find(), looks like it takes into account different options. But, still, it may happen that PHP CLI is different from PHP for Web.
Right now we're make some changes to eliminate some of such calls at all, while some of them will be still there.

[aohorodnyk]

Hello,

You can set to variable environment const with name PHP_PATH and value "path to you php execution file" or you can remove your local php from MAC OS and set your php from MAMP like default php version.
PhpExecutableFinder has more variables which you can use. If you want, you can see it in code

P.S. how to set environment const http://stackoverflow.com/questions/146354/setting-php-variables-in-httpd-conf

Thanks

[verklov]

@bit32, we'd like to hear from you. Did the advice by @dropsql help you resolve the issue you were having?

[Viveur]

I symlinked MAMPs version of PHP to /usr/bin/php to get it installed at the time. @dropsql's comment wasn't added for another 2 weeks.

Since you asked tho I have downloaded the latest version of Magento2 and have run through two fresh installations of Magento 2 with the symlink removed (entering /usr/bin/php -v at the terminal returns OS X's inbuilt version of PHP).

The first I did by manually setting a environment variable of PHP_PATH to the MAMP path as described by @dropsql. The installation process went ahead without error.

I then unset the environment variable with: unset launchctl unsetenv PHP_PATH and attempted a new installation. I was somewhat surprised to find that the installation process also worked without error. Not sure if this is due to updated code in Magento2 or some persistent change on my end.

[muasir]

This issue was present when we used exec. Now we don't use exec, so this shouldn't be a problem.