[Bug]: macOS fresh Herd installation, no php binary installed in ~/Library/Application Support/Herd/bin/

[stevenmaguire]

Platform

macOS

Operating system version

macOS Ventura 13.6.7

System architecture

ARM64 (M1, M2, etc)

Herd Version

1.13.0 (Build 37)

PHP Version

No response

Bug description

I've just done a fresh install of Herd on macOS and despite the installation appearing to complete successfully, the ~/Library/Application Support/Herd/bin/ directory does not contain a php binary and therefore none of the PHP-based features are working. I have used the UI to install PHP 8.2, 8.3, and 8.4 and all of those binaries appear in the expected app support bin directory - just no php binary.

The application was installed by downloading the DMG from the Herd website, unpacking, dragging to Applications shortcut.

There are no other instances of Herd installed on the machine nor are there any other instances of PHP installed on the machine.

All shells reloaded and profiles re-sourced. Profiles do include auto-added path prepends as expected - including the annoying duplicate inclusions.

After installation, this is what happens when attempting to check the versions, an expectation documented on the installation guide:

steven at minime in ~/.files on main*
$ herd --version
/Users/steven/Library/Application Support/Herd/bin/herd: line 13: php: command not found
Error finding executable PHP. Quitting for safety.
Provided output from find-usable-php.php:

steven at minime in ~/.files on main*
$ php --version
-bash: php: command not found
steven at minime in ~/.files on main*
$ laravel --version
env: php: No such file or directory
steven at minime in ~/.files on main*
$ composer --version
env: php: No such file or directory

Steps to reproduce

No response

Relevant log output

No response

[stevenmaguire]

It's worth noting, I am not 100% sure that a php binary is expected to be in that bin directory. I've had Herd installed on the machine before and it worked just fine but I never looked closely at the bin directory. I'm assuming it will need a php bin target in there to "route" to the correct php version as the OS/user attempts to use PHP. But maybe I am wrong? If no php bin is expected to be in that directory, how are things expected to be linked up?

[stevenmaguire]

Well, after banging my head on this for a while, I figured out how to get past this issue and it's not intuitive - likely some room to improve this sharp edge in an upcoming release of the software.

When looking at the Herd context menu immediately after install, it shows the three versions of PHP installed and the "current" version highlighted as 8.2 - the first version I installed via the UI.

When in this state, I get the results in my original post above - no php bin to be found.

I used the Herd context menu and selected 8.3 to be the "current" version and wouldn't you know it, the php binary appeared as a symlink as (assumed) expected.

So, problem solved and lesson learned but I do think there is some room to update the application to check for the existence of this symlinked binary at logical events during the app's runtime. If the app thinks that 8.2 is "current" when viewing the context menu immediately after installation, it should be same to assume that the underlying symlinked binary is present too. Otherwise, perhaps don't show an arbitrary or misleading "current" PHP version in the menu. Show some other status that says, "No current PHP version selected; select one" or something to that effect?

[mpociot]

@stevenmaguire Did you migrate from Laravel Valet?
When migrating from Valet, we install all PHP versions that you previously used in Valet. Maybe there's an issue with how we "activate" a given PHP version in this scenario.

[stevenmaguire]

Did you migrate from Laravel Valet?

In this instance, I did not. Valet was not installed on the machine and I did a fresh install of Herd. Now that I know what the problem was, I know what to do to fix it so it's not a blocker per se. If you think there is some effort that could be made to shave off this potential rough edge, I think it would help. If nothing else, an added FAQ to the Common Troubleshooting docs on the site may be useful - even if it links to this GH issue.