Brew installed pie not found after self-update

[paulinevos]

What are you trying to do?
Update pie by running pie self-update.

What platform, and PIE version are you using?

🥧 PHP Installer for Extensions (PIE) 1.3.7, from The PHP Foundation
You are running PHP 8.4.17
Target PHP installation: 8.4.17 nts, on Linux/OSX/etc arm64 (from /opt/homebrew/Cellar/php@8.4/8.4.17/bin/php)

where pie
/opt/homebrew/bin/pie

Steps to reproduce the issue

1. Install pie using brew
2. run pie self-update
3. run pie -v -- will show "command not found" for pie

What do you expect to happen?
The issue is resolved by updating using brew and running brew link --overwrite pie. However, I'd expect pie self-update to do this painlessly so the user doesn't have to figure out what to fix.

What is actually happening
After running pie self-update, the pie command in no longer found.

Complete logs/output

pie self-update
🥧 PHP Installer for Extensions (PIE) 1.3.7, from The PHP Foundation
Updating using the stable channel.
You are running PHP 8.4.17
Target PHP installation: 8.4.17 nts, on Linux/OSX/etc arm64 (from /opt/homebrew/Cellar/php@8.4/8.4.17/bin/php)
You are currently running PIE version 1.3.7
✅ Verified the new PIE version
✅ PIE has been upgraded to 1.4.0
➜  mongo-php-library git:(7a8a596a) ✗ sudo pie install mongodb/mongodb-extension
sudo: pie: command not found
➜  mongo-php-library git:(7a8a596a) ✗ pie install mongodb/mongodb-extension
zsh: permission denied: pie

Anything else?
I'm unsure if this is specifically because of the fact that it's brew-installed, but that's my first instinct.

[asgrim]

Hmm; I can reproduce this (ish) I get similar behaviour with slightly different messages;

➜  ~ pie --version
🥧 PHP Installer for Extensions (PIE) 1.3.10
➜  ~ pie self-update -v       
🥧 PHP Installer for Extensions (PIE) 1.3.10, from The PHP Foundation
Updating using the stable channel.
You are running PHP 8.4.18
Target PHP installation: 8.4.18 nts, on Linux/OSX/etc arm64 (from /Users/james/Library/Application Support/Herd/bin/php84)
Using pie.json: /Users/james/.pie/php8.4_853d1b802e469fa6434707be0d5b93cc/pie.json
You are currently running PIE version 1.3.10
Newer version 1.4.0 found, going to update you... ⏳
Verifying release with digest sha256:b4a50f2c1c22eb72321ee462039b71f180c2c86778d8fa2a7c18812766468c3d...
Verifying using: /opt/homebrew/bin/gh attestation verify --owner=php /private/var/folders/kn/j9zkd1c146x05gb9pl1qf0cw0000gn/T/pie_self_update_jd2gosch9j474aCRQlg
✅ Verified the new PIE version
Writing new version to /opt/homebrew/bin/pie
Password:
✅ PIE has been upgraded to 1.4.0
➜  ~ pie --version
zsh: permission denied: pie
➜  ~ brew link --overwrite pie
Warning: Already linked: /opt/homebrew/Cellar/pie/1.3.10
To relink, run:
  brew unlink pie && brew link pie
➜  ~ pie --version            
zsh: permission denied: pie
➜  ~ brew unlink pie
Unlinking /opt/homebrew/Cellar/pie/1.3.10... 3 symlinks removed.
➜  ~ brew link --overwrite pie
Linking /opt/homebrew/Cellar/pie/1.3.10... 4 symlinks created.
➜  ~ pie --version
🥧 PHP Installer for Extensions (PIE) 1.3.10

That said, I think the issue is the same; PIE writes itself to the same location it runs from; in this case /opt/homebrew/bin/pie - but that is originally a symlink.

My initial thought to solve this was to realpath(..) that directory (for me, resolves to /opt/homebrew/Cellar/pie/1.3.10/bin/pie); but then I thought, we'd be replacing /opt/homebrew/Cellar/pie/1.3.10/bin/pie (with 1.3.10) with the newer version (1.4.0, at the time of writing); whilst it would work, I'm not sure it's ideal as the version wouldn't match the path it is in.

I'm wondering if a better approach is we should check if we're installed using brew (e.g. "my path contains /opt/homebrew/Cellar" or similar check - maybe we can check the homebrew cellar path or something); and then suggest the user upgrades with brew upgrade pie to get the latest, instead.

A similar approach could be taken with the EPEL distribution in Fedora; we could add the check into PIE if we're using that install mechanism (not sure how to detect that off my head) and suggest they update with yum/dnf instead. This also reduces the need for the EPEL maintainer to apply that patch to disable pie self-update. @remicollet would that be of any help? If so, do you know how PIE could detect if it is installed with EPEL distribution at runtime?

[remicollet]

A similar approach could be taken with the EPEL distribution in Fedora; we could add the check into PIE if we're using that install mechanism (not sure how to detect that off my head) and suggest they update with yum/dnf instead. This also reduces the need for the EPEL maintainer to apply that patch to disable pie self-update.

We don't patch to disable pie self-update, the condition already exists, we only add a message about how to update

See https://src.fedoraproject.org/rpms/pie/blob/rawhide/f/pie-rpm.patch#_28

@remicollet would that be of any help? If so, do you know how PIE could detect if it is installed with EPEL distribution at runtime?

Using shell

# rpm --query --file /usr/bin/pie
pie-1.4.1-1.fc43.remi.noarch

Using PHP (but requiring rpminfo ext)

$ php -r 'var_dump(rpmdbsearch("/usr/bin/pie", RPMTAG_INSTFILENAMES)[0]);'
array(5) {
  ["Name"]=>
  string(3) "pie"
  ["Version"]=>
  string(5) "1.4.1"
  ["Release"]=>
  string(11) "1.fc43.remi"
  ["Summary"]=>
  string(28) "PHP Installer for Extensions"
  ["Arch"]=>
  string(6) "noarch"
}

[asgrim]

@remicollet thank you - that is helpful - and yes that makes sense, because you're not running in PHAR 👍

[asgrim]

A few checks we can perform, for improved messaging:

• Check if the path contains /opt/homebrew/Cellar and don't update - suggest they should update with brew upgrade pie
• Check rpm --query --file /usr/bin/pie to see if it resolves (indicates it was installed with RPM) and don't update - suggest they should update with dnf upgrade pie (or just dnf upgrade)
• Check if we're running from a symlink and don't update - warning about this; display the realpath() for the symlink
• Check if the (resolved) PIE path is readonly and don't update - warning that the realpath is readonly

  if (!(fileperms($actualPieBinary) & 0x0080)) throw new PieIsReadonlyException()

[alcaeus]

• Check if the path contains /opt/homebrew/Cellar and don't update - suggest they should update with brew upgrade pie

You'll want to check for both /opt/homebrew/ and /usr/local, as the latter is still used when installing on an Intel Mac. Theoretically users could have a custom directory, but this is not recommended by Brew so I think we can disregard that scenario.

[asgrim]

Thanks - good shout; although /usr/local is not really something we should block for self-update (since that's where it goes on Linux); I'll investigate a bit more to cover Intel OSX 👍

[remicollet]

• Check rpm --query --file /usr/bin/pie to see if it resolves (indicates it was installed with RPM) and don't update - suggest they should update with dnf upgrade pie (or just dnf upgrade)

Probably better to replace /usr/bin/pie by the path of the used command (ex: could be manually installed as /usr/local/bin/pie which is for nomal user before /usr/bin in the search path)

[derickr]

Thanks - good shout; although /usr/local is not really something we should block for self-update (since that's where it goes > on Linux); I'll investigate a bit more to cover Intel OSX 👍

That's what I run (in QEMU) and I can confirm the default brew is in /usr/local but pie is a symlink to something with Cellar in the name:

derick@macOS xdebug % which pie
/usr/local/bin/pie
derick@macOS xdebug % ls -l /usr/local/bin/pie 
lrwxr-xr-x  1 derick  admin  27 15 Apr 09:19 /usr/local/bin/pie -> ../Cellar/pie/1.4.0/bin/pie
derick@macOS xdebug % ls -l /usr/local/Cellar/pie/1.4.0/bin/pie 
-r-xr-xr-x  1 derick  admin  12468102  8 Apr 10:08 /usr/local/Cellar/pie/1.4.0/bin/pie