Description
Q | A |
---|---|
Bug report? | no |
Feature request? | yes |
BC Break report? | no |
RFC? | yes |
Symfony version | 3.2.x |
It's stated in #20434 that env variables currently does not support being used in place for service names, which limits it's usefulness.
Is there plans to provide a best practice around this?
Possible alternatives:
A. Change how configuration of handlers are done to allow switching service on runtime Does not make sense as pointed out by @stof below, often you need to compile config depending on a handler, this is something to do at compile time and not run time
B. Introduce a compile time env variable support as well so we can also be allowed to inject variables at compile time without having to resolve to custom env.php kind of solutions.
C. If there are no plans to tackle this with additional features, improvment potential here is to improve doc and more clearly throw on use like this as done in #20687.
Example:
[Symfony\Component\DependencyInjection\Exception\EnvParameterException]
Incompatible use of dynamic environment variables "MAILER_TRANSPORT" found in parameters.
Exception trace:
() at vendor/symfony/symfony/src/Symfony/Component/DependencyInjection/Compiler/Compiler.php:137
(...)
[Symfony\Component\DependencyInjection\Exception\InvalidArgumentException]
Unable to replace alias "swiftmailer.mailer.default.transport.real" with actual definition "%env(MAILER_TRANSPORT)%".
Exception trace:
() at vendor/symfony/symfony/src/Symfony/Component/DependencyInjection/Compiler/ReplaceAliasByActualDefinitionPass.php:63
(...)
[Symfony\Component\DependencyInjection\Exception\ServiceNotFoundException]
You have requested a non-existent service "%env(MAILER_TRANSPORT)%".
Exception trace:
() at vendor/symfony/symfony/src/Symfony/Component/DependencyInjection/ContainerBuilder.php:795
(...)