Vendor mode in a custom project, with custom extensions

[yoramdelangen]

What does this PR do?

Minor changes for allowing to use the library in a custom project instead of forking and adjusting code within the "project base".

Thread of the question can be found in and also fix #687.

Added the following options to adjust:

• Adding a custom command
• Allow for custom changes for BuilderProvider after initializing.
• By adding the following tree/namespace you can add custom extensions project-based without forking:

➜  poc-vendored-php-static-cli git:(main) tree --gitignore
.
├── bin
│   └── spc
├── composer.json
├── composer.lock
├── config
│   ├── ext.json
│   ├── lib.json
│   └── source.json
└── src
    ├── ConsoleApplication.php
    ├── MyCommand.php
    └── builder
        ├── extension
        │   └── snowflake.php
        ├── linux
        │   └── library
        │       └── snowflake.php
        ├── macos
        │   └── library
        │       └── snowflake.php
        └── unix
            └── library
                └── snowflake.php

Project example can be found here. In the example I have added pdo_snowflake extension, because I need it, and it gives a good example.

Compling works, only the testing part fails at the moment due to PHP not using the pdo_snowflake.so file.

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 you modified *.php, run composer cs-fix at local machine.
• 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.

[henderkes]

I have a hard time understanding how this will lead to less maintenance than a fork. But if you'd like it for modularity reasons, I'll give it a shot locally over the next days.

But since you've mentioned snowflake.so, using the glibc build and loading shared extendions is the absolutely easiest approach with zero maintenance on your part.

[yoramdelangen]

I mainly aim these changes to use for extensions like snowflake and a extension we created ourself(compilation is similar to Snowflake). In case other people want to have their extensions available for the project without forking, this would be the easiest solution in stead of having a fork that can conflict on every commit pulling from upstream.

So php-static-cli can be used as a framework of compile extensions for your own project.

[yoramdelangen]

@DubbleClick I think the changes are ready, only to make it work in "vendor-mode" in the CI pipeline requires binary paths changes. Instead of $WORKDIR/bin/spc it should be something like: vendor/crazywalecc/bin/spc or symlink the vendor/crazywhalescc/bin to $WORKDIR/bin.

[henderkes]

I'll leave both of your PR's up to @crazywhalecc, he's the owner of the project and I don't see myself in a position to make decisions crucial to the project structure or workflow on my own. He'll be back from vacation soon!

I really like the workflow PR though!

[yoramdelangen]

@DubbleClick I don't have the need for the customize builder provider(yet). So I removed it for now.

I wait for him to be back :) Hopefully he is refreshed after his holiday!

Please feel free to point anything out of the ordinary, if you find any

[crazywhalecc]

Unfortunately I ended my vacation a long time ago, but at the same time I was extremely busy at my day job.🥲

Don't worry though, I should have time to resolve remaining issues this week.

[henderkes]

Ah welcome back, I hope you had a good time. I'm really excited for the shared extensions, once it goes live we'll have full package support for frankenphp + frankenphp-xdebug and frankenphp-ffi in around a week.

[crazywhalecc]

I'm not sure how much customization people will have for private extensions, but I think we should add skeleton commands once vendor mode is officially available.

vendor/bin/spc dev:ext-skel myext
# And it will generate config, builder, add composer autoload if not exists, etc...
# BTW I also want it works in project mode, it will also save my time adding new extension.

At the same time, for xxx.json, I also plan to implement xxx.custom.json, just like env.ini. So this may not be a simple update.

[crazywhalecc]

If private extensions are supported, perhaps an extension source of type=local is required?

[crazywhalecc]

I will take over this PR after thinking carefully about the implementation of vendor mode. Once everything is ready, I am open to reviews from anyone.

In the meantime, I have almost finished the commands to generate skeletons of extensions and libraries: #715, which also helps with vendor mode.

[crazywhalecc]

I think we can start this now. The main work can be divided into several parts:

• [Hard] Write development docs
• [Easy] Declare internal callable APIs
• [Hard] Write skeleton generation commands (WIP)

In addition, I think it may be possible to implement other binary builds in vendor mode. For example, we can reuse spc dependencies to build static python, static vim and other components. Maybe no one will need them, but it should be feasible.

As for single-file build support I mentioned before, I feel like now is not the right time and might cause maintenance chaos instead. In the future, we can try to extend based on the current vendor model, and it may be better to use SPC as a base framework to develop.

TLDR: For the current PR, I will make a small amount of modifications in the future to support the most basic vendor functions. After that, the vendor mode support of the skeleton command will be improved.

[henderkes]

Yes, this will actually also help quite a bit with spc-packages. I ended up rewriting a lot of sloppy logic to substitute behaviour already implemented in spc. Which is kind of fine for the scope the project has at the moment or that is planned, but I might do a proper rewrite with vendored spc mode once it exists.