-
-
Notifications
You must be signed in to change notification settings - Fork 101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Phar class not found #988
Comments
This looks really strange: I really don't think it's possible for the PHAR class to not exist yet especially since Box itself uses it. Is the script used really the one you linked? Isn't there a namespace declared or something? |
I can't explain it either. I tried executing box from global installation and from project installation. Same result. I just added a I also checked if the Phar extension is enabled. It is. |
Would you have a reproducer by any chance? Out of curiosity could you also try to run the Box Symfony E2E test? |
It should be make e2e_symfony_runtime or something |
I created a minimal repository with which I was able to reproduce the issue: https://github.com/it-bens/box-test |
The E2E test leads to the same result: $ make e2e_symfony_runtime
> php fixtures/build/dir018/new-bin/console --version --no-ansi \
1>dist/dir018/expected-stdout \
2>dist/dir018/expected-stderr
fixtures/build/dir018/new-bin/console cache:pool:clear cache.global_clearer --env=prod --ansi
// Calling cache clearer: cache.global_clearer
[OK] Cache was successfully cleared.
fixtures/build/dir018/new-bin/console cache:clear --env=prod --ansi
// Clearing the cache for the prod environment with debug false
[OK] Cache for the "prod" environment (debug=false) was successfully cleared.
rm -rf fixtures/build/dir018/var/cache/prod/*
bin/box.phar compile --working-dir=fixtures/build/dir018 --no-parallel --ansi
____
/ __ )____ _ __
/ __ / __ \| |/_/
/ /_/ / /_/ /> <
/_____/\____/_/|_|
Box version dev-main@25cb301 2023-04-10 13:25:29 UTC
// Loading the configuration file "/home/box/fixtures/build/dir018/box.json.dist".
🔨 Building the PHAR "/home/box/fixtures/build/dir018/new-bin/console.phar"
? Checking Composer compatibility
> Supported version detected
? No compactor to register
? Adding main file: /home/box/fixtures/build/dir018/new-bin/console
? Skip requirements checker
? Adding binary files
> 3 file(s)
? Auto-discover files? Yes
? Exclude dev files? Yes
? Adding files
> 1275 file(s)
? Generating new stub
- Using shebang line: #!/usr/bin/env php
- Using banner:
> Generated by Humbug Box dev-main@25cb301.
>
> @link https://github.com/humbug/box
? Dumping the Composer autoloader
In ComposerOrchestrator.php line 102:
Could not dump the autoloader.
In ComposerOrchestrator.php line 102:
The command "'/usr/local/bin/composer' 'dump-autoload' '--classmap-authoritative' '--no-dev' '--ansi'" failed.
Exit Code: 255(Unknown error)
Working directory: /tmp/box/Box33769
Output:
================
Generating optimized autoload files (authoritative)
Error Output:
================
Executing script cache:clear [KO]
[KO]
Script cache:clear returned with error code 255
!! PHP Fatal error: Uncaught Error: Class "Phar" not found in /tmp/box/Box33769/vendor/autoload_runtime.php:11
!! Stack trace:
!! #0 /tmp/box/Box33769/new-bin/console(12): require_once()
!! #1 {main}
!! thrown in /tmp/box/Box33769/vendor/autoload_runtime.php on line 11
!!
Script @auto-scripts was called via post-autoload-dump
compile [--debug] [--no-parallel] [--no-restart] [--dev] [--no-config] [--with-docker] [--composer-bin COMPOSER-BIN] [--allow-composer-check-failure] [-c|--config CONFIG] [-d|--working-dir WORKING-DIR]
make: *** [Makefile.e2e:318: e2e_symfony_runtime] Error 1 |
Same issue here. Try to run box compile with GitHub actions. Added some debug points in Output
When running |
Is there such a thing available in your CI? Running the command with |
Not that I'm aware of. When running In the output it is visible that two kind of ini files are used:
|
@maartendekeizer isn't your issue a timeout rather than |
The timeout did not happen without |
@maartendekeizer I am a bit confused by your CI though: https://github.com/Markei/kopio/blob/main/.github/workflows/build-phar.yml How is PHP installed there? It appears you pick whatever ubuntu latest has which IMO is a bad idea. I am not sure if it's the root of the problem, as I am not aware of a PHP binary that comes without the PHAR extension, but looking at your workflow that's the only thing I can pick up. |
I actually missed #988 (comment). Might be another lead I'll have to check ASAP. I'm focusing on finishing to fix the |
Upgraded to 4.4.0, issue still exists. Add a dump of php_ini_scanned_files(). See https://github.com/Markei/kopio/actions/runs/6525975372/job/17719227836 In the step Cache warm up multiple ini files are loaded, each ini file will activate an extension (for instance Phar). |
Setting BOX_ALLOW_XDEBUG=1 will fix the problem which bring us maybe to the composer xdebug handler https://github.com/composer/xdebug-handler/blob/main/src/XdebugHandler.php |
Indeed if removing the restart fixes it it likely a bug there. @maartendekeizer do you have any local (potentially via docker) reproducer? I would like to avoid pulling in johnstevenson without one if I can help it |
Sorry local under Windows and no xdebug. Unsure how to reproduce this is under Docker, but the linked repository can be used as an example. I see that Box is using XdebugHandler too. Thinking about a solution it should be something like: |
Ha I see, that would make sense, will give it a go ASAP |
@maartendekeizer I am a bit perplexed as I can't reproduce your issue here: #1089 |
Hm actually didn't check but could also be from the Flex plugin too... |
I managed to reproduce and isolate the issue in https://github.com/box-project/box/actions/runs/6592295374/job/17912645537#logs. My findings:
Looking at https://github.com/symfony/flex/blob/3e8d6c423092ca89dd8fb998ddb9d7a91139e52f/src/ScriptExecutor.php#L94 I have no clue why this would result in a PHP process with non-sensical ini values. For the record: this is not a problem of Box restarting the process. I mean it is linked, but Composer is executed within it and the PHP scripts started by flex also work fine. So I am a bit at a loss |
I figured out https://github.com/symfony/flex/blob/3e8d6c423092ca89dd8fb998ddb9d7a91139e52f/src/ScriptExecutor.php#L120C9-L120C9 is a bad way to find out if the xdebughandler has restarted composer. The code will check for a specific environment variabel, if it set it assumed it will need to use another ini file instead of the used php.ini (in the case this tmp ini is created in the no-xdebug-restart and is passed via PHPRC env to composer). Cleaning the env will not trigger the bad flex code and will continue to use the right tmpIni. Successfull run: https://github.com/maartendekeizer/box/actions/runs/6593003554/job/17914732375 |
That does the trick! Prob worth fixing on Flex side :o |
> [!WARNING] > Note: this PR is more of draft. I am not confident I understand fully the issue neither that this is the right fix (and I could not test it). Do NOT assume this code just works. After a lot of digging in box-project/box#988, @maartendekeizer could identify the root of the issue. My understanding is that Flex tries to detect if the current PHP process was restarted by Composer and forwards its restarted settings to the sub-processes it is going to launch. There is currently two things done: - symfony#91 which if took code from SensioDistributionBundle. - symfony#899 which kind of followed the suite. I suspect the mentioned code predates `composer/xdebug-handler`. Now with this package, there is two things to take into account: - The `composer/xdebug-handler` API is likely much safer, more robust and a lot less hacky to use. - There is other applications that can restart a PHP process. As an example Box restarts the PHP process to be able to correct the `phar.readonly` setting that cannot be changed at runtime. It matters as the restarted process by be executing a Composer command. As mentioned in the warning, I could not test this, not even run the tests locally, so I would be careful about this PR. I just wanted to give a base about a potential fix with context about the original issue encountered. On my side to not have to wait on Flex and avoid the users to have to update it to have the fix, Box launches its Composer commands with `COMPOSER_ORIGINAL_INIS=''` to avoid Flex to trigger this bad piece of code.
- Use the persistent setting: any sub-process should use the same settings. - Reset `COMPOSER_ORIGINAL_INIS` to avoid the buggy Flex code (see symfony/flex#995). Closes box-project#1089, box-project#988.
- Use the persistent setting: any sub-process should use the same settings. - Reset `COMPOSER_ORIGINAL_INIS` to avoid the buggy Flex code (see symfony/flex#995). Closes #1089, #988.
Closed by #1091, thank you a lot @maartendekeizer for figuring it out |
Bug report
The box compile command results in a
Class "Phar" not found in/.../autoload_runtime.php:11
error. PHAR is installed. Readonly is Off. The'/usr/local/bin/composer' 'dump-autoload' '--classmap-authoritative' '--no-dev' '--ansi'
command doesn't fail if executed manually in the project directory.box.json.dist
Output
Because it's a Symfony project:
autoload_runtime.template
The text was updated successfully, but these errors were encountered: