So, back at square one i guess :)

#20533 reverted the integrity check for accessing services, before the container builder is actually compiled. Making it real tricky, yet convenient. However, it is done for the right reasons, for now.

Where does that leave us? Will it be put back? And what is the alternative/right approach?

Imo. we all agree the check is needed to keep the container trusty, but we lose major flexibility on simple services (ones that can actually be resolved fully at some point before compilation).

Some ideas;

• (1) Keep it as is. If this was already decided by now, please close :) Basically saying to the user; with great power, comes great responsibility; do as you like / whatever works for you. Until it breaks that is :))
• Deprecate it!
  • (2) Teach the user to do a different approach in user-land (ie. just initialize a service hardcoded, where needed, when needed). As there will be many tickets about this i guess.
  • (3) Introduce a 2nd container, compiled and accessible, before compiling the 1st container. The user can configure required services as usual. Ie. what about tagging required services with bootstrap, making the full service available on booting, ie. one config and no duplicate service definitions.
  • (4) Allow the user to get a service without compiling the current container (ie. clone it, compile it, then get it). However this basically acts the same as option 1 (keeping it as is), whenever it breaks / doesnt work anymore you still need to revise your approach.
  • (5) Detect which services are safe, and which arent out-of-the-box (the holy grail).
  • (6) Allow compiler passes to run last with scope on a (sub)compiled version of the container, still allowing to modify the actual container. Doing it in 2 steps, the other way around.