cannot build dir018: Could not dump the autoloader.
I'm still stuck on #1497 , so I figured I'd try to get the example working.
Are these the correct instructions?
composer global require humbug/box:dev-main
git clone [email protected]:humbug/box
cd box/fixtures/build/dir018
touch .env.local.php
composer install
~/.config/composer/vendor/bin/box compile
My results:
composer install
Installing dependencies from lock file (including require-dev)
Verifying lock file contents can be installed on current platform.
Nothing to install, update or remove
Generating autoload files
Executing script cache:clear [OK]
Executing script assets:install public [OK]
26 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
Run composer recipes at any time to see the status of your Symfony recipes.
Executing script cache:clear [OK]
Executing script assets:install public [OK]
tac@system76-pc:~/tacman/box/fixtures/build/dir018$ ~/.config/composer/vendor/bin/box compile
____
/ __ )____ _ __
/ __ / __ \| |/_/
/ /_/ / /_/ /> <
/_____/\____/_/|_|
Box version dev-main@22c7e70
// Loading the configuration file "/home/tac/tacman/box/fixtures/build/dir018/box.json.dist".
🔨 Building the PHAR "/home/tac/tacman/box/fixtures/build/dir018/new-bin/console.phar"
? Checking Composer compatibility
> Supported version detected
? No compactor to register
? Adding main file: /home/tac/tacman/box/fixtures/build/dir018/new-bin/console
? Skip requirements checker
? Adding binary files
> 2 file(s)
? Auto-discover files? Yes
? Exclude dev files? Yes
? Adding files
> 1429 file(s)
? Generating new stub
- Using shebang line: #!/usr/bin/env php
- Using banner:
> Generated by Humbug Box dev-main@22c7e70.
>
> @link https://github.com/humbug/box
? Dumping the Composer autoloader
In ComposerOrchestrator.php line 174:
Could not dump the autoloader.
In ComposerOrchestrator.php line 177:
The command "'/usr/local/bin/composer' 'dump-autoload' '--classmap-authoritative' '--no-dev' '--ansi'" failed.
Exit Code: 255(Unknown error)
Working directory: /tmp/box/Box56890
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 Symfony\Component\Dotenv\Exception\PathException: Unable to read the "/tmp/box/Box56890/.env" environment file. in /tmp/box/Box56890/vendor/symfony/
dotenv/Dotenv.php:552
!! Stack trace:
!! #0 /tmp/box/Box56890/vendor/symfony/dotenv/Dotenv.php(105): Symfony\Component\Dotenv\Dotenv->doLoad()
!! #1 /tmp/box/Box56890/vendor/symfony/dotenv/Dotenv.php(148): Symfony\Component\Dotenv\Dotenv->loadEnv()
!! #2 /tmp/box/Box56890/vendor/symfony/runtime/SymfonyRuntime.php(107): Symfony\Component\Dotenv\Dotenv->bootEnv()
!! #3 /tmp/box/Box56890/vendor/autoload_runtime.php(16): Symfony\Component\Runtime\SymfonyRuntime->__construct()
!! #4 /tmp/box/Box56890/new-bin/console(12): require_once('...')
!! #5 {main}
!! thrown in /tmp/box/Box56890/vendor/symfony/dotenv/Dotenv.php on line 552
!!
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]
Here's an asciicast : https://asciinema.org/a/ZedxKQl6x8kN2HSzpXLjAjyEU
I think if I could just see a trivial Symfony "hello world" console command compiled to a phar, I'd be able to do some of the updates for Symfony 7. The tests seem to pass (well, some skipped tests) so maybe it's a configuration issue, a path somewhere.
Thanks.
I think it would be wiser to use make e2e_symfony_runtime, at least in the past I often had cache related issues with that test hence the Makefile does a few cleanup things there.
I wonder if the issue you have is that the wrong environment is being used? Could also be I'm interpreting this wrong, it's hard to tell
Can you give me some guidance on how to run that from the command line?
Hello @theofidry
I've a same error but with this output
The command "'/usr/local/bin/composer' 'dump-autoload' '--classmap-authoritative' '--no-dev' '--ansi'" failed.
Exit Code: 126(Invoked command cannot execute)
Working directory: /tmp/box/Box66536
Output:
================
Generating optimized autoload files (authoritative)
Error Output:
================
Composer could not detect the root package (bartlett/graph-uml) version, defaulting to '1.0.0'. See https://getcomposer.org/root-ve
rsion
> vendor/bin/captainhook install --configuration=captainhook.json --only-enabled
sh: 1: vendor/bin/captainhook: Permission denied
Script vendor/bin/captainhook install --configuration=captainhook.json --only-enabled handling the post-autoload-dump event returne
d with error code 126
As the configuration dump-autoload does not provide option to configure, we are not able to choose to :
- dump the autoloader without running composer script, because my error came from there (
captainHook) is declared on mycomposer.json
"scripts": {
"post-autoload-dump": "vendor/bin/captainhook install --configuration=captainhook.json --only-enabled"
}
Composer runtime is able to do so : composer dump-autoload --no-scripts
I'm a bit confused I tried to reproduce this but it works just fine (locally or in the CI). I had to install and update symfony/flex locally though
Can you provide a repo? Then we can clone and try in our environments.
@tacman the repro was on this repo:
- clone the repo
- composer global install symfony/flex
make e2e_symfony
Thanks. I'm able to get this repo to compile successfully, but I'm confused about what I need to do to compile my repo. Even after I copy Makefile, Makefile.e2e and bin/box.phar, when I compile my code I continue to get
./ciine.phar PHP Fatal error: Cannot redeclare interface Symfony\Component\Runtime\RuntimeInterface (previously declared in phar:///home/tac/g/sites/phar-demo/ciine.phar/vendor/symfony/runtime/RuntimeInterface.php:19) in /home/tac/g/sites/phar-demo/vendor/symfony/runtime/RuntimeInterface.php on line 19 Symfony\Component\ErrorHandler\Error\FatalError^ {#27 #message: "Compile Error: Cannot redeclare interface Symfony\Component\Runtime\RuntimeInterface (previously declared in phar:///home/tac/g/sites/phar-demo/ciine.phar/vendor/symfony/runtime/RuntimeInterface.php:19)" #code: 0 #file: "./vendor/symfony/runtime/RuntimeInterface.php" #line: 19 -error: array:4 [ "type" => 64 "message" => "Cannot redeclare interface Symfony\Component\Runtime\RuntimeInterface (previously declared in phar:///home/tac/g/sites/phar-demo/ciine.phar/vendor/symfony/runtime/RuntimeInterface.php:19)" "file" => "/home/tac/g/sites/phar-demo/vendor/symfony/runtime/RuntimeInterface.php" "line" => 19 ]
But the sample code in this directory compiles and runs.
./dist/dir012/console.phar
Symfony 6.4.22 (env: prod, debug: false)
Usage:
command [options] [arguments]
Options:
What I was hoping for is a "Interatactions" repo with 2 files, HelloCommand.php and GoodbyeCommand.php that compiles to interact.phar, then I can run it anywhere with
interact.phar hello Dolly --locale=es
Hola, Dolly
interact.phar goodbye Dolly --locale=es
Adios, Dolly
I can create that repo in a few minutes (my own repo, https://github.com/survos-sites/ciine-cli is slightly more complicated, but not much).
If I create a interact Symfony application, what are the steps to turn it into a phar? If I create it, can you help me compile it?
I think the difference is that yours in Symfony7. I'll look into it
Any progress on a working Symfony 7 demo?
Symfony 8/PHP 8.5 will be out in 10 weeks. Is it too early to start bugging you about that? ;-)
Based on my past experiences, most dependencies of PHP-Scoper/Box take a few months to get up to speed so yes, definitely too early.
I couldn't check the demo yet, it is on my list though.
Friendly ping...
Is there anything I can do to help with this?
I have a project where I need to do a simple upload (files+metadata) and I could create a bundle for it, but it doesn't need to be integrated with Symfony, it could be a standalone app, and this seems like the right tool to use to turn my simple Symfony app into a CLI application.
@tacman I did a PR to your project.
I am not entirely sure I follow what was attempted, but two things to note:
- you do need to dump the .env file, like you would do for a prod application (mentioned in the doc)
- there was some steps missing from the composer.json (mentioned in the doc)
- you tried to rename
bin/console: it is trivial to rename the directory (you need to configureextra.bin-dirin yourcomposer.json,fixtures/build/dir018-bishas that example), but renamingconsoleitself is not supported by Flex: https://github.com/symfony/flex/blob/f356aa35f3cf3d2f46c31d344c1098eb2d260426/src/ScriptExecutor.php#L102) - it is recommended to add
binin yourcomposer.json(and that way you don't need to configure it inbox.jsoneither).
I just listed things as they are, but I need to go through that list again to update the docs as well as I noticed one or two things either outdated or that could be phrased better or have an example.
Opened #1550 to improve the docs a bit.
Thanks! Getting closer, but I'm not quite getting it yet. I'll re-try in a few days.
Very much appreciate you tweaking my code!
ping me when you'd like me to try again with the updated documentation.
@theofidry My issue referenced by https://github.com/box-project/box/issues/1507#issuecomment-3109071781 still exists with version 4.6.10
@llaville could you give me a reproducer?
I've been using castor (https://github.com/jolicode/castor) and I find it easier to work with than Makefile, in part because I'm a Symfony snob so I think everything made with Symfony is better.
Castor 1.0 was just recently released, but it's been under development for a few years.
IMHO, worth a look.
I have enough rabbit holes as it is, no way I'm migrating the Box & PHP-Scoper and/or Infection makefiles to castor 😰
It is a cool project though, and Jolicode a cool company too, so glad to hear you're enjoying it :)
could you give me a reproducer?
@theofidry Of course. I don't think it's related to my project, because I reproduced it with other projects too. So to follow my previous comment that details error I've got.
- clone my project https://github.com/llaville/graph-uml.git
- install default dependencies with
composer update(I used latest version 2.8.12) - you can install/or not git hooks at composer installation (it's not really important here)
> vendor/bin/captainhook install --configuration=captainhook.json --only-enabled
Install pre-push hook? [Y,n] y
✔ pre-push installed
Install pre-commit hook? [Y,n] y
✔ pre-commit installed
- change the content of
box.jsonfile and modify the directive to"dump-autoload": true - compile (try it) the PHAR with
box compile -c box.jsoncommand (I used recent version 4.6.10@6dc6a13) - and you will get error as described previously
@theofidry Any news ?
@llaville I think your issue is unrelated.
What I find suspicious is your script on dump autoload: it means you would have captain script installed & executed when box will orchestrate composer to dump the autoload.
When box execute the dump-autoload, the code has already been "optimized" (e.g. dev deps removed), so executing such dev scripts seems ill-suited.
Sad to see this situation ... and I will continue to use my workaround then (do not use the dump-autoload box feature)
An alternative is, before you start the box process, you remove the captainhook script from the post-autoload-dump.
I don't use captainhook so maybe I'm missing the point, I'm scratching my head at what use it would have for when the PHAR is being dumped.
The quick solution is easy : do not allows composer scripts when running the Composer dump-autoload command !
Here is a compilation result I got, when I enable Box dump-autoload feature.
Details
Box version dev-main@728081b
// Loading the configuration file "box.json".
🔨 Building the PHAR "/shared/backups/bartlett/graph-uml/graph-uml.phar"
? Checking Composer compatibility
> '/usr/local/bin/composer' '--version' '--no-ansi'
> Version detected: 2.8.12 (Box requires ^2.2.0)
> Supported version detected
? No compactor to register
? Adding main file: /shared/backups/bartlett/graph-uml/bootstrap.php
? Adding requirements checker
? Adding binary files
> No file found
? Auto-discover files? No
? Exclude dev files? Yes
? Adding files
> 159 file(s)
? Generating new stub
- Using shebang line: #!/usr/bin/env php
- Using banner:
> Generated by Humbug Box dev-main@728081b.
>
> @link https://github.com/humbug/box
? Dumping the Composer autoloader
> '/usr/local/bin/composer' 'dump-autoload' '--classmap-authoritative' '--no-dev' '-v' '--ansi' '--no-scripts'
Generating optimized autoload files (authoritative)
Generated optimized autoload files (authoritative) containing 26 classes
Composer could not detect the root package (bartlett/graph-uml) version, defaulting to '1.0.0'. See https://getcomposer.org/root-version
> command: Bamarni\Composer\Bin\BamarniBinPlugin->onCommandEvent
[bamarni-bin] Calling onCommandEvent().
> post-autoload-dump: Bamarni\Composer\Bin\BamarniBinPlugin->onPostAutoloadDump
[bamarni-bin] Calling onPostAutoloadDump().
? Removing the Composer dump artefacts
? Compressing with the algorithm "GZ"
> Warning: the extension "zlib" will now be required to execute the PHAR
? Setting file permissions to 0755
* Done.
💡 1 recommendation found:
- The "dump-autoload" setting can be omitted since is set to its default value
No warning found.
// PHAR: 192 files (184.93KB)
// You can inspect the generated PHAR with the "info" command.
// Memory usage: 14.28MB (peak: 15.12MB), time: 509ms
Simple code patch follows
Details
diff --git a/src/Composer/ComposerProcessFactory.php b/src/Composer/ComposerProcessFactory.php
index 27312b6a..c62aff7d 100644
--- a/src/Composer/ComposerProcessFactory.php
+++ b/src/Composer/ComposerProcessFactory.php
@@ -87,6 +87,7 @@ class ComposerProcessFactory
if ($this->ansi) {
$composerCommand[] = '--ansi';
}
+ $composerCommand[] = '--no-scripts';
return $this->createProcess($composerCommand);
}
Unfortunately it's a bit of a heavy handed solution :/
In your case, it totally makes sense, but some apps use scripts as part of the "app building" process. E.g. for a Symfony app with flex it needs the flex plugin to execute the scripts.
I suggest then to make it configurable as you did with dev files and https://box-project.github.io/box/configuration/#excluding-dev-files-exclude-dev-files directive
I suggest a new config option like exclude-composer-scripts (bool default false to make it Backward Compatible)
And we could fix the patch like this
Details
diff --git a/src/Composer/ComposerProcessFactory.php b/src/Composer/ComposerProcessFactory.php
index 27312b6a..f6f5c74a 100644
--- a/src/Composer/ComposerProcessFactory.php
+++ b/src/Composer/ComposerProcessFactory.php
@@ -88,6 +88,10 @@ class ComposerProcessFactory
$composerCommand[] = '--ansi';
}
+ if (true === $noScripts) {
+ $composerCommand[] = '--no-scripts';
+ }
+
return $this->createProcess($composerCommand);
}
This is my last attempt !
If you're not agree, I will let down usage of dump-autoload (after all it works for me when it's disabled)
If you're not agree, I will let down usage of dump-autoload (after all it works for me when it's disabled)
I think in your case it's not doing anything because you don't enable the removal of dev deps, so the only thing you might loose is the class map not being optimized.
I suggest then to make it configurable as you did with dev files and https://box-project.github.io/box/configuration/#excluding-dev-files-exclude-dev-files directive
I don't like that solution, because now there is that for scripts, but then there is plugins & a different dump autoload & whatever.
But you are right that it is too restrictive at the moment. WDYT of enabling string|bool and allow the user to specify what they want, e.g. @composer dump-autoload --no-plugins --no-scripts.
In Box I can pick up the @composer and replace it by the Composer binary Box picks up.
But you are right that it is too restrictive at the moment. WDYT of enabling
string|booland allow the user to specify what they want, e.g.@composer dump-autoload --no-plugins --no-scripts.
👎
Sounds better than having dump-autoload + exclude-composer-scripts + exclude-composer-plugins + dump-autoload-mode...
For both the user and code maintainability (this is another 3+ options to add...)