Unclear how plugins should indicate a configuration failure

[asottile]

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

[asottile]

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]

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]

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]

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]

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)