to accept env placeholders in the semantic config of the bundle and have them work, the requirements are:
don't write beforeNormalization steps in the Configuration that rely on the values of settings (the logic in DoctrineBundle > supporting a shortcut config by moving keys around is fine as it does not care about the values themselves)
same for validate steps in the Configuration
don't write logic in the DI extension that relies on inspecting the values of those settings before injecting them in DI parameters or service definition arguments
the only solution for that is to get that DSN out of the object graph of the cache warmer. Otherwise, it will still be resolved when passing it to the instantiation of that part of the graph, even if it is wrapped in another object
If the client does not accept a DSN directly, the solution is to use a factory service doing that parsing. This is what Doctrine bundle does with its ConnectionFactory
See discussion here about the misunderstanding how exactly env params work.
My comments:
I guess the only thing which the builder could validate is if either the DSN or individual config values are set and have env-placeholder syntax
meaning, the build-time validation is
Is this variable set and does it have env-placeholder like syntax?
the actual value is not inspected, only if it looks like an env placeholder which could get evaluated into a correct value at runtime
Additional note
Maybe a nice DX upgrade: some "explainer" command which tells you how it works in your current container, telling you why a specific env var vas resolved during build time and which weren't.
Notes by @stof:
See discussion here about the misunderstanding how exactly env params work.
My comments:
Additional note
Maybe a nice DX upgrade: some "explainer" command which tells you how it works in your current container, telling you why a specific env var vas resolved during build time and which weren't.