Bug in Windows

[arshidkv12]

[asgrim]

Is this still occurring? I can't reproduce.

[arshidkv12]

It causes issues if I move the PHP executable path to the Downloads or Desktop folder.

[asgrim]

It causes issues if I move the PHP executable path to the Downloads or Desktop folder.

Sorry I don't understand what you're doing here - please could you provide an isolated set of steps to reproduce the issue you're seeing?

[arshidkv12]

Please check the path in image. But it has no issue, if I execute c:/php/php.exe

[asgrim]

@arshidkv12 you really need to provide me with more information please, and can you provide the actual text output instead of screenshots? Please also use -v to provide me with more information.

What version of PHP is your C:/php/php.exe too?

[vasilvestre]

Please check the path in image. But it has no issue, if I execute c:/php/php.exe

What I understand is that you need to use --with-php-path set to your download dir that contains PHP.exe.
Note that installing PHP in your download dit isn't a good practice.

[adrianowead]

This problem is happening to me too. The documentation requires that the .zip and .dll files follow the format: php_{extension-name}-{tag}-{php-maj/min}-{ts|nts}-{compiler}-{arch}

PIE downloads normally, but when extracting, it renames the file to {extension-name}.dll in the temporary download folder.

So, before moving to the final extensions directory, this check is performed, and an error occurs stating that the DLL was not found with the requested name pattern.

I don't think the problem is the location of php.exe, but rather the PIE flow that changes the name before verification.

[asgrim]

PIE downloads normally, but when extracting, it renames the file to {extension-name}.dll in the temporary download folder.

So, before moving to the final extensions directory, this check is performed, and an error occurs stating that the DLL was not found with the requested name pattern.

Would you be able to provide a stack trace / full verbose output please? The DLL isn't named until after that exception is thrown, so I don't think that's the issue, but I don't have enough information to look into this further at the moment, as I cannot reproduce it...

[adrianowead]

There's probably something wrong with my environment. Even though I'm using a Windows container, the installation worked normally. Both packages have the same structure, following the same naming pattern in the .zip and .dll files, but it installs in one computer and not in the other.

I tend to believe it's a problem in one of my environments.

[adrianowead]

Good news!

I found the exact cause of the problem. The first version of my package actually had the wrong DLL name.

However, even after making the correction, the reported error occurred. I investigated a bit more and realized that the Composer cache was persisted. That's why it worked on one computer and not on the other.

After removing the Composer cache, the installation worked perfectly.

So I believe PIE might have an option similar to Composer --no-cache.

Thanks for your attention!

[asgrim]

Great! Thanks for the feedback @adrianowead - I've noted the idea about --no-cache in #392 as that is totally feasible and would have helped in your situation 👍 will close this ticket then!