warn when providing unsupported options in the config file?

[ltalirz]

As of now, making a typo in the configuration file (e.g. resulting in a wrong key name) results in the setting being silently ignored. It would be very useful to be warned about this.

One may think that validating the config file should be the role of the configuration provider but in reality the configuration provider may just be a parser of the file format, reused by several click config file options (for different click commands).
I.e. it would be nice if the click option could let the configuration provider know which configuration settings it expects (or handle the validation itself).

Haven't looked into how easy it is to get this from click.

[phha]

Sorry for the late answer.

I fully agree with you that this should not (and indeed can not) be the responsibility of the configuration provider.

I've looked into this and Click's architecture makes it extremely difficult to implement this.

configuration_option uses is_eager=True to force Click to invoke the Callback before all other options (this is in itself problematic, since other options may set is_eager=True themselves).

It then populates Context.default_map to ensure that the values of the remaining options are resolved as expected by Click's own resolution mechanism.

The problem here is that at the moment of invocation the Callback can not know which options will be invoked by Click. It merely injects the default values and relies on Click to do the right thing afterwards. This also leads to inconsistent handling of the allow_extra_args parameter.

I suppose you could argue that it is Click's responsibility to check default_map against the supplied options, taking into account the allow_extra_args parameter, but I don't know how receptive they would be to fixing this on their side.

[phha]

There might be a chance to fix this after pallets/click#590 is addressed.

[RemiTorracinta]

Hello, just want to voice my support for a change in this direction, as it caused a bug for me today.

It does make sense that a change may be required on Click's part.

It might make sense to say as much over there.

[kdeldycke]

FTR, I just added strict configuration validation to click-extra so that you can easily prevent any unsupported option to be loaded.

See: kdeldycke/click-extra@bd791b3