allow to use custom runtime

[allan-simon]

close #56

[allan-simon]

now it should be good @mnapoli

[DaMitchell]

Is there anything stopping this from being added?

[mnapoli]

@DaMitchell what would be your use case?

[DaMitchell]

@mnapoli We have a set of parameters we store in Parameter Store that we want to pull down and make available to the application, and we are testing that currently by extending the Symfony runtime wrapping the runner and then loading them in via DotEnv.

Something like what @allan-simon has included in #56.

[mnapoli]

Got it. Is it something that could be implemented in Kernel::boot() or a similar method?

Is there any reason to implement it in a custom runtime? (I'm trying to be exhaustive and figure out if this is really something worth the maintenance effort)

[allan-simon]

in my case it was because the env and debug attribute used to construct the kernel were overwritten by the dotenv value , and so Kernel::boot is already too late

[t-richard]

@allan-simon maybe it didn't worded in boot because of something similar to what I found in this PR #37

That said, adding support for any runtime is out of the scope of this bridge for now.

I fear that if we support that, we end up with people wanting to use runtimes for roadrunner, reactphp or swoole in Lambda for example and that may not work as expected in a Lambda environment.

That being said, if that's a real blocker, we could allow to specify a runtime but only if it's an instance of SymfonyRuntime.

That way we support use cases like yours but constrain it to something we know works and that we can maintain.

[allan-simon]

@t-richard I've checked, and I think here it was not the issue, but if I remember my investigation (i'ts been a while so I may recall incorrectly) it was really a "by design" , as the Kernel constructor already expect to receive env variables , which mean they need to be ready by the time you instantiate it.

I understand that opening to any kind of custom runtime may widen too much the scope and make it unbearable to support in term of human time, so your proposition of limiting it to sub-class of SymfonyRuntime sounds like a good compromise to me.

[DaMitchell]

@mnapoli I understand trying to be exhaustive with a requirement like this. We have and internal framework we use across multiple projects so I was just looking for a method that would require the least amount of project level change and moving it into the runtime "model" seemed to fit that.

I will take a look at doing something in Kernel::boot() as an alternative path if this isn't a change that makes it in.

Limiting it to an instance of the SymfonyRuntime would also support our case.

[Nyholm]

I appreciate this.

[mnapoli]

Thanks, to piggy-back on the comments above let's merge this with a check that the runtime extends SymfonyRuntime

[allan-simon]

sure no problem

[allan-simon]

@mnapoli done, I've tested locally by monkeypatching my vendor

[Nyholm]

I've rebased the PR and fixed the CI issues

[Nyholm]

Thank you for the PR and thank you for merging