Repository navigation
Unclear how plugins should indicate a configuration failure #1108
Description
In GitLab by @pjacock on Aug 6, 2019, 02:42
I have read http://flake8.pycqa.org/en/latest/plugin-development/plugin-parameters.html#accessing-parsed-options
I am working on a plugin which successfully sets and receives additional configuration values. However, I wish to validate the configuration once (as early as possible), and may need to indicate an error to flake8 signalling it to abort. The simple option of raising a ValueError within parse_options does not work gracefully:
...
@classmethod
def add_options(cls, parser):
...
# Define option "--our_config_file"
@classmethod
def parse_options(cls, options):
...
if not os.path.isfile(options.our_config_file):
raise ValueError("Could not find specified file: %r" % options.our_config_file)
...This has the desired effect of aborting flake8 early, but with an ugly traceback.
Is there an expected approach I have overlooked, or would documenting this with a try/except in flake8 be preferred?
I think the change would be in the provide_options method here:
https://gitlab.com/pycqa/flake8/blob/3.7.8/src/flake8/plugins/manager.py#L186
Activity
asottile commentedon Apr 3, 2021
In GitLab by @asottile on Aug 6, 2019, 06:43
I need to introduce a public type (or reuse the argparse / optparse types) - I noticed this issue as well while working on flake8-typing-imports and adding custom logic for python version
asottile commentedon Apr 3, 2021
In GitLab by @pjacock on Aug 6, 2019, 07:48
Either should work - I can support older flake8 installations by trying to import the proposed new exception (for a clean abort), and if that fails just raise a
ValueError(or similar) to get the abort with traceback.asottile commentedon Apr 3, 2021
In GitLab by @asottile on Aug 6, 2019, 08:48
I might wait until this is moved to argparse so there's a more obvious choice of type hierarchy that flake8 doesn't have to maintain
asottile commentedon Apr 3, 2021
In GitLab by @sigmavirus24 on Aug 6, 2019, 08:55
Are we tracking the work to move over to argparse? I built the abstraction layer with the hope of following quickly on with that work, but obviously got 'round to it.
asottile commentedon Apr 3, 2021
In GitLab by @asottile on Aug 6, 2019, 09:02
I'll need it to solve https://gitlab.com/pycqa/flake8/issues/541 so I'm planning to track it there
I've already started poking at how this would happen -- the abstraction layer makes it pretty convenient to move however there's still some things that will be tricky (in particular the
callback_*stuff)