Skip to content

[Runtime] Allow frameworks to overwrite default Runtime class #60249

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

Open
Kingdutch opened this issue Apr 21, 2025 · 3 comments
Open

[Runtime] Allow frameworks to overwrite default Runtime class #60249

Kingdutch opened this issue Apr 21, 2025 · 3 comments
Labels

Comments

@Kingdutch
Copy link

Description

Problem

Currently the Symfony runtime plugin outputs the following configuration for the runtime (and similar behaviour for the runtime options):

$runtime = $_SERVER['APP_RUNTIME'] ?? $_ENV['APP_RUNTIME'] ?? 'Symfony\\Component\\Runtime\\SymfonyRuntime';

This provides three ways to set the runtime:

  1. Prioritizing server configuration
  2. Allowing the runtime to be set by environment variable
  3. Falling back to the project's composer.json configuration

Each of these options are aimed at providing the end-user (the project developer) with the ability to change the runtime. However, it provides no way for a framework besides Symfony to suggest a default while still enabling user change.

Context

I'm attempting to introduce the Symfony Runtime component into Drupal core. To make this an adoptable change it's not feasible to ask all developers that maintain a Drupal project to update their server configuration, environment, or composer.json.

In theory the SymfonyRuntime works fine and the DrupalKernel is executed using the HttpKernelRunner. However, we would like to use our own runner so that we can adopt the Revolt event loop. The SymfonyRuntime does not provide a way for sometihng that implements HttpKernelInterface to register a more specific runner.

Proposed solution

If no runtime class is specified in the composer.json file, then provide an additional $FALLBACK_RUNTIME (or $FRAMEWORK_RUNTIME?) variable that's checked before falling back to SymfonyRuntime. This allows frameworks to easily set that variable before including autoload_runtime.php.

Example

Replacing

        $runtimeClass = $extra['class'] ?? SymfonyRuntime::class;

        unset($extra['class'], $extra['autoload_template']);

        $code = strtr(file_get_contents($autoloadTemplate), [
            '%project_dir%' => $projectDir,
            '%runtime_class%' => var_export($runtimeClass, true),
            '%runtime_options%' => '['.substr(var_export($extra, true), 7, -1)."  'project_dir' => {$projectDir},\n]",
        ]);

with

        if (null !== $runtimeClass = $extra['class'] ?? null) {
          $runtimeClass = var_export($runtimeClass, true);
        }
        else {
          $runtimeClass = '$FALLBACK_RUNTIME ?? ' . var_export(SymfonyRuntime::class, true);
        }

        unset($extra['class'], $extra['autoload_template']);

        $code = strtr(file_get_contents($autoloadTemplate), [
            '%project_dir%' => $projectDir,
            '%runtime_class%' => $runtimeClass,
            '%runtime_options%' => '['.substr(var_export($extra, true), 7, -1)."  'project_dir' => {$projectDir},\n]",
        ]);

Would allow a framework to set its own fallback using

$FALLBACK_RUNTIME = DrupalRuntime::class;
require_once 'autoload_runtime.php';

Any Symfony application would keep working as expected and ignore the unset $FALLBACK_RUNTIME.

@nicolas-grekas
Copy link
Member

Interesting :)

Did you consider configuring another template for autoload_runtime? I think that could work.

@Kingdutch
Copy link
Author

Thanks for your reply @nicolas-grekas !

When you posted this I didn't quite know what you meant. As far as I understand, only the root package is able to configure the autoload_runtime template. However, the code that's shipping the front-controller in this scenario would be the Drupal framework. So as library we wouldn't be allowed to do what you're suggesting.

I've since seen in php-runtime/runtime that they do some magic with the autoloader to make the runtime discoverable. But I couldn't find any documentation for that behaviour so I'm unsure if that's feasible for us.

Was that what you were suggesting instead? How would we go about that? Is adding the autoload configuration enough?

@nicolas-grekas
Copy link
Member

What about adding this to your front-controller?

$_ENV['APP_RUNTIME'] ??= $_SERVER['APP_RUNTIME'] ?? 'Your\Runtime';

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants