Hi there! Have you considered using your own environment variable to specify your deployment type, then writing some code to check that value and set an appropriate Timbre config and/or appropriate output-fns? That’d be much simpler than trying to get Timbre to resolve nested symbols.

Yes that is kind of what I am doing now. The reason I started looking at other approaches was that I had multiple apps using timbre and this would allow me to remove the init code from them and just specify the timbre config to be used.

If I understand correct currently it is not possible to completely configure timbre through a edn file as you need to be able to provide functions. This would be a way to allow that.

but perhaps its not worth it and maybe its error prone?

But if you like the idea I could give it a shot 🙂

> The reason I started looking at other approaches was that I had multiple apps using timbre and this would allow me to remove the init code from them and just specify the timbre config to be used. Okay gotcha, thanks for explaining 👍 But you would still need to have code in each app to define the various output-fns, right? Would selecting an output fn based on your env-var be much more code? I’m reluctant to pursue the nested symbol resolution for a few reasons: 1. Implementing this correctly may be non-trivial. 2. Understanding and documenting the behaviour may be non-trivial. For example: do we also resolve symbols for appenders? What about other config options? How do we decide what gets resolved? What happens when a resolve fails? 3. Config-based resolution wouldn’t work for ClojureScript, meaning different config behaviour between Clj and Cljs. 4. Embedding symbols meant for resolution in config can be a little brittle. It’s relatively easy for a var name to change and lose sync with external config. I’m skeptical that any value-add here would be worth the complexity, especially since there’s already a simple + reliable way of achieving the same result. Does that seem reasonable?

> But you would still need to have code in each app to define the various output-fns, right? In my particular case there is a common library/ns that define the output-fns But yes it sounds reasonable. Thanks for taking your time to consider the suggestion 👍

You’re welcome, best of luck!