I'm personally fine doing that but we should throw a deprecation somewhere in 5.4.
Maybe at compile time in the DI component would be appropriate?

I'm personally fine doing that but we should throw a deprecation somewhere in 5.4. Maybe at compile time in the DI component would be appropriate?

In ContainerBuilder::compile() directly?

In ContainerBuilder::compile() directly?

Possibly yes. In a place that allows the deprecation to be collected for the profiler (with other compile-time deprecations).

👍 for Composer 2.1

but let's remove the change on ErrorHandler to allow using the component with less constraints if that doesn't matter much

Oh btw, if Symfony 6.0 is Composer 2.1 only, we could release Flex 2, which would bump to the same, with a cleaned up code base (eg the http downloader which is now in C2)

I've bumped to 2.1 and reverted the ErrorHandler changes.

What about moving this to frameworkbundle actually? That would give better guarantees for what we consider "Symfony 6 apps", without imposing a restriction on standalone DI users.

What about moving this to frameworkbundle actually?

What do you mean by "this"? The willBeAvailable() method?

I mean the composer constraint

The usage of the composer runtime api is in the DI component, not in FrameworkBundle. So that's where the dependency is.

If we keep the "class_exists" check that is in place, DI doesn't have a dependency on C2.1.
This change is motivated by the will to provide a predictable behavior accross the board.
Adding the constraint to FWB found achieve this goal.

My fear is that by adding the constraint to DI, ppl that try to upgrade to SF6 with C1 will get dependencies resolved just fine... with DI 5.4...

If we keep the "class_exists" check that is in place, DI doesn't have a dependency on C2.1.

But that class_exists() check is precisely what bothers me. It's causes the unpredictable behavior. Alternatively, we could let willBeAvailable() throw on the 6.0 branch if the Runtime API is not available.

This change is motivated by the will to provide a predictable behavior accross the board. Adding the constraint to FWB found achieve this goal.

… for full-stack Symfony apps. The component standalone would still behave undpredictably if willBeAvailable() is used.

My fear is that by adding the constraint to DI, ppl that try to upgrade to SF6 with C1 will get dependencies resolved just fine... with DI 5.4...

We could solve that by either adding the Runtime API dependency to FWB as well or by letting FWB conflict with DI 5.4.

The component standalone would still behave undpredictably if willBeAvailable() is used.

if willBeAvailable() is used yes.

this might not be enough a reason to force requiring C2.1 in DI, nor to make FWB 6 conflict with DI 5.4

We could solve that by either adding the Runtime API dependency to FWB as well or by letting FWB conflict with DI 5.4.

I'm all for adding the bump to fwb. Not for conflicting. And then I wonder why we should add it to DI. We like optional deps everywhere else.

We like optional deps everywhere else.

Okay, what about my proposal of letting willBeAvailable() throw on the 6.0 branch if the Runtime API is not available? The unpredictable behavior would be replaced with a clear error message and by adding the runtime API to FWB's dependencies we make sure, a Symfony 6 app won't run into the exception.

Throwing works for me, with a deprecation on 5.4 :)

Here you go: #43804

Ready.

Thank you @derrabus.