Order of configuration file and environment variable value

[Midnighter]

I have a click argument set up in the following way:

@click.argument("model", type=click.Path(exists=True, dir_okay=False),
                envvar="MODEL", required=False)

and I have also configured a corresponding configuration file. This works perfectly.

My only question/concern is whether the order can be determined? Currently, the configuration is read and passed into the commands context so that the configuration file is always preferred over the environment variable.

[nixjdm]

I have a related concern, but I'll state it a little differently.

I did not understand the docs at first glance, and had to read https://github.com/click-contrib/click-configfile/blob/master/click_configfile.py#L468-L499 to figure out what's going on. The first section listed when you construct your own class ConfigSectionSchema is the "Primary", which means that it will have it's keys / values loaded into the top level of the ctx.default_map dict. This has the effect that a key in this section has the following precedence: CLI > Configuration file > Environment > Default.

That's great, and the order I want. The problem for me is controlling the other sections in the config file. I really want that precedence of CLI > Configuration file > Environment > Default, but I'm finding it hacky / difficult to achieve. Every other section (not the primary) is loaded as a dict into the ctx.default_map, so it would look like {'non-primary-section': {'key': 'val1'}, 'key-from-primary-section': 'val2'}.

This effectively removes the config-provided key from the precedence entirely, to give you just CLI > Environment > Default, plus the value from the config available inside ctx.default_map['non-primary-section'] to process manually. While you have the data from the config, how should I determine whether or not to use it? I can't easily tell if I got the original ctx var as part of the cli, environment var, or default value, so I don't know if I should override it or not with the value from the config file.

Possible Improvements / Solutions:

1. I understand the desire to keep the namespaces clean from the different sections, so perhaps the default behavior should stay. However, I would love the ability to denote whether a SectionSchema should assume the behavior of the primary schema manually. If I could, then I could choose to merge as many schemas into ctx.default_map as I want. I imagine for many projects this would not be an issue. I see this as an additional feature in this project.

2. A clean way of determining the source of the params on a command. If we can find out if it's from one source or the other, we can force the same precedence. I don't think click exposes this right now. It could, potentially though, and just be another kind of meta data.

Thoughts?

[kdeldycke]

I stumble upon a similar issue and ended up creating my own extension: click-extra. In which:

• the default CLI > Configuration file > Environment > Default is respected
• the configuration file structure is derived from the parameters of the CLI
• the configuration values are recursively merged into the defaults