I'm going to call for a better solution for the problem.
I really don't like passing the config through provider units.
Runtime configuration should not be a provider's property (logically it isn't). I understand the need for environment info to be present when instantiating templates, but I think we don't need to get providers involved in this dynamic process (providers are fairly static monsters).
What I would advocate doing instead is:
- pass config to the code that does the instantiation (IDK how many steps in the callstack the config would have to be passed). or,
- exposing the current config (or current SA instance) through a module interface, I'm doing something similar for the remote functionality, see remote.py: 75-87
I'm going to call for a better solution for the problem.
I really don't like passing the config through provider units.
Runtime configuration should not be a provider's property (logically it isn't). I understand the need for environment info to be present when instantiating templates, but I think we don't need to get providers involved in this dynamic process (providers are fairly static monsters).
What I would advocate doing instead is:
- pass config to the code that does the instantiation (IDK how many steps in the callstack the config would have to be passed). or,
- exposing the current config (or current SA instance) through a module interface, I'm doing something similar for the remote functionality, see remote.py: 75-87