Verbosity as Resource Option triggers an error

[Yannick-Dayer]

The fix to have the correct log level in config files (implemented in #6) has the side effect of causing an error when verbosity_option is also a config option, and its entry_point_group argument is not provided.

    @click.command(cls=ConfigCommand)
    @clapper.click.verbosity_option(
        # entry_point_group="config_group",  # Commenting this causes an error
        cls=ResourceOption,
    )
    my_command(**kwargs):
        pass

Calling my_command -v causes the following error:

TypeError: The ResourceOption class is not meant to be used this way. See package documentation for details.

[anjos]

I can confirm I experienced that. I had to remove all occurrences of that from my code.

[Yannick-Dayer]

It shows the conflict that the verbosity option could be set in a config file.

I can mitigate this problem (and keep back-compatibility) by making the option "eager" only if there is no way to set it in the config.
There would be two cases:

• When verbosity_option is an instance of ResourceOption, the logger will not be set during the config (previous behavior: the logging level of the app can be set either by the config or by the -v option).
• If verbosity_option is not a ResourceOption, the logger level will be set correctly in the config files (new behavior, the logging level of the config files and the app can be set by the -v option).

It seems a good compromise, without trying to pre-load the files to search for a possible verbosity config before loading the configs.

[183amir]

can we parse the option twice and call the callback twice if eager mode is set?

[Yannick-Dayer]

Even then, what is the behavior when verbosity_option is a ResourceOption and verbose is set in a config file?

When we have the verbose value, the config loading will have already been done, and the logs in the config files are already out; too late to change the log level of those.