@ro0NL as#19608 is merged, I guess you can close this one ? :)

@Ener-Getick : My PR was only removing "dead code". It doesn't un-deprecate getting a service instance from theContainerBuilder.

But I'm not convinced we need something like the newServiceAwareDefinition. We could simply consider any service set usingContainerBuilder::set should be a "building-time only" service and allow to get it, but won't be available after compilation. It feels weird and I'm not convinced by this "feature" neither, but currently services set directly in theContainerBuilder are vanished after compilation anyway.

Most important is the logic ofContainerBuider::get +MergeExtensionConfigurationPass::process for now.

ServiceAwareDefinition is somewhat a shortcut forset() +setDefinition(), so this can be left out yes. Consider it a poc :)

edit: @Ener-Getick i can rebase.. :)

@ogizanagi theServiceAwareDefinition allows for having the service+definition at the same time, asset()overwrites definitions for the same id.

So if you have a non-synthetic definition + the ready to use service, you are stuck now. Not sure how common that is, on the other hand#19606 is poc of exactly that.

@ro0NL : My point is that you probably don't need having a service definition for services designed to be used during the container building time only (but is it even a good idea to depend on any kind of service in this phase ?). :/
I think that's the only thing needed for the use-case of exposing kernel & bundles "metadata".
Otherwise, either you'll get a service definition into the compiled container that will never be used at runtime, either you'll have to set the service twice (during and after the container is compiled).

Thusmy suggestion about exposing abooting_kernel during the container build, which would simply be aKernelInterface decorator throwing an exception for unsafe methods, and will never be available at runtime (use thekernel service then). ^^

EDIT:

So if you have a non-synthetic definition + the ready to use service, you are stuck now. Not sure how common that is

As you said, not sure there are real use cases for this. Why would you need a container to build a service you're able to build yourself and would not be used at runtime ? Eventually you only need a way to share things during compilation time.
I think we're probably going in the wrong direction. TheContainerBuilder should probably not behaves as aContainer. Maybe theContainerBuilder is only missing ashared context somehow (immutable or locked at some point preferably. It's not safe to rely on if things can be put in at different building phases such as in the extension loading).

Could be.. this is just a generic approach that allows for it. If the component really needs it, i dont know. Perhaps nice to have. But yeah, my usecase is definitely kernel+bundles ;-)

Abooting_kernel service will also do 👍

@ro0NL : regarding the part I've added after editingmy comment above, here is a naive & straightforward implementation of a contextualized container builder, allowing to share some context during the build time, before compilation of the container:master...ogizanagi:contextualized_container

Here, theContext is locked right before callingCompiler::compile, ensuring nothing can mutate it appart from theKernel::getContainerBuilder() method (actually,Kernel::registerContainerConfiguration() andBundleInterface::boot() can too). But we can imagine (if legit) locking the context only after some point (in a dedicated compiler pass), making the context mutable at some point (extensions) but "safe to use" only in compiler passes (which is where people tended to rely wrongly on services before the container was build before theContainerBuilder::get() method was deprecated).

Of course, I don't expect this to be a perfect nor legit implementation, but simply exploring and giving more hints on how to proceed considering your uses cases. :)

@ogizanagi im thinking this thru.. maybe you're right on how we try to solve this and not being the right direction. It feels workaroundish i guess.

The ContainerBuilder should probably not behaves as a Container

• Makes sense. Period. (before/while compilation that is)
• How does this reflectContainerBuilder::set? Should it even be allowed then?

I was also heading "context" way, and just had a crazy idea:ContainerBuilder::getContext():Container.

How does this reflect ContainerBuilder::set? Should it even be allowed then?

Indeed, it should not. I guess it was part of the idea behind theget deprecation, but it still allows to set synthetic services, which are vanished after compilation, and moreover not merged during build phase. So it may not allow callingset at all.

ContainerBuilder::getContext():Container

Yeah...thought about that too, but I'm not fan of giving visibility to the fact we use a container to build a container... 😅 At least the foolish lockableContext implementation hides that fact a little.

I dont mind :) I think we're too much used toone container being the almighty thing. It's a pattern, eventually it's legit 😉

Another, bridge too far, idea; each bundle defines it's own container(s) in the ecosystem. Container as a service 😱

Anyway, maybe focus this PR on deprecatingset() first then? So at least the current behavior is consistent and clear.

Anyway, maybe focus this PR on deprecating set() first then? So at least the current behavior is consistent and clear.

IMHO it should be the subject of another PR deprecating the wholeset usage.