Log level is leaking between invokations: hack to force-reset it

[kdeldycke]

The log level is set once and for all in the option in the plugin.

That mean in a test suite that is playing with the log-level defaults, the level set within a previous test is carried upon the next. This happened to me in my project where I tested the effect of defaults loaded from the default_map.

I found a way to fix this issue by resetting the log level after each CLI execution.

This fix should be merged upstream to this plugin. One way to properly does it is I guess to leverage the resource management utilities available in Click.

[untitaker]

this seems feasible. I see one other option, that is to enforce the log level in a log filter, then the log level can live on the click context instead of being global state. click context is a threadlocal too, so this would make it threadsafe

[kdeldycke]

Since my initial bug report I revisited this issue. I have a better understanding of Click's architecture. And you're right. the Context was indeed designed to be thread-safe, so that might be a good way to address the issue.

In the mean time I also tried to pack all my workarounds into a standalone option: https://github.com/kdeldycke/click-extra/blob/aff2623194606dde322cf2bed454ae3805c04214/click_extra/logging.py#L46-L85

See how I ended up using a combo of callback and ctx.call_on_close() to set-up and reset the level. This seems to neutralize my hack that requires any meddling with default_map itself.