fix SPC_NO_MUSL_PATH not working in .env.ini

[DubbleClick]

What does this PR do?

prior to this patch, setting SPC_NO_MUSL_PATH has to be defined in the environment. setting it in .env.ini had no effect.

Checklist before merging

If your PR involves the changes mentioned below and completed the action, please tick the corresponding option.
If a modification is not involved, please skip it directly.

• [] If it's an extension or dependency update, make sure adding related extensions in src/global/test-extensions.php.
• If you changed the behavior of static-php-cli, update docs in ./docs/.
• If you updated config/xxx.json content, run bin/spc dev:sort-config xxx.

[crazywhalecc]

It seems that the dependency management of spc itself is more difficult. Limiting spc to only support the latest version of PHP (8.4) may reduce a lot of work. WDYT?

[DubbleClick]

Php 8.4 to run spc? I don't see an issue with that.

Only compile php 8.4? I personally wouldn't mind because I immediately update anyway, but I think a lot of users would be upset. I think unless necessary, we should support building all supported versions (8.2+).

Which do you mean?

[crazywhalecc]

@DubbleClick It is easy to confuse the PHP version that spc supports building with the PHP version that spc itself depends on.

What I mean is that we will distribute the standalone spc anyway, so the PHP version that spc depends on can always be kept up to date, reducing the pain of composer dependencies. Of course, the PHP that spc can compile is still 8.0~8.4, which will not change.

But an additional consideration is that many other workflows that depend on this project may use git to pull spc, and a violent incompatible update will conflict with the existing PHP version, which may be a potential problem.

[DubbleClick]

But an additional consideration is that many other workflows that depend on this project may use git to pull spc, and a violent incompatible update will conflict with the existing PHP version, which may be a potential problem.

Inconsequential, in my opinion. We can require php 8.4 to run spc and when someone doesn't wish to install php 8.4, they can use the standalone binary, frankenphp or another static php 8.4 binary to run. If someone set up a deployment using SPC and were silly enough to clone the main branch, that's on them. It's common knowledge to always require specific version when they don't wish to actively develop.

I would even say we could/should only support building php 8.2+ going forward. <8.2 is out of support for php, so it should be for us too. If someone would like to build old versions, they can checkout an release of spc.

[DubbleClick]

I would tackle that in another PR, though.