Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

warn when providing unsupported options in the config file? #11

Open
ltalirz opened this issue Jun 2, 2019 · 4 comments · May be fixed by #35
Open

warn when providing unsupported options in the config file? #11

ltalirz opened this issue Jun 2, 2019 · 4 comments · May be fixed by #35

Comments

@ltalirz
Copy link
Contributor

ltalirz commented Jun 2, 2019 •
edited
Loading

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.
@ltalirz ltalirz mentioned this issue Jun 2, 2019
Merged
@phha
Copy link
Owner

phha commented Jul 26, 2019

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
Copy link
Owner

phha commented Jul 26, 2019

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

@RemiTorracinta
Copy link

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
Copy link

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

This was referenced Mar 20, 2023
Closed
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Raise click.BadParameter if config contains unknown keys sphuber/click_config_file
4 participants
@kdeldycke @phha @ltalirz @RemiTorracinta