Skip to content

select/ignore/enable/disable is a mess #260

Open
@jakkdl

Description

@jakkdl

Status quo:

  • ignore or extend-ignore ASYNC error codes in config is not possible, as flake8 gives an error
  • when running flake8-async as a plugin, --ignore and --extend-ignore is possible on the command-line, flake8 does not seem to enforce the three-letter rule there
  • select does not currently have the validation rules enabled that ignore does.
  • --select and --ignore are not supported when running as standalone
  • it's always possible to use --enable and --disable.
  • when running as a plugin, we add individual error codes for ASYNC9xx to the default_ignored codes
  • when running as standalone, we set the default of --disable to ASYNC9.

Implications:

  • if running as plugin, you have to select/--select ASYNC9xx codes to enable them. Trying to enable them will do nothing.
  • But if you want to default-enable ASYNC9xx rules, and disable them individually, you need to use a combination of select/--select and --disable (or --ignore on the CLI).
  • if running as standalone, you have to --enable ASYNC9xx codes. --select gives errors

This is... a mess. And it feels like --[extend-]ignore on the CLI, and select could get hit with the three-letter validation rules at any point which would make it impossible for end-users to enable ASYNC9xx codes unless they downgrade flake8 / we update flake8-async.

suggestions:

  1. Stop calling option_manager.extend_default_ignore
  2. Always default --disable to ASYNC9
  3. in parse_options, read options.select and parse out any selected ASY... codes, adding them to --enable
  4. same thing with options.ignore -> --disable, in case --ignore has been used on the CLI
  5. [maybe] register --select and --ignore as options when running as standalone.
    • this would make it slightly easier to switch from plugin to standalone, but the added complexity might not be worth it. e.g. flake8-async --select=ASYNC --ignore=ASYNC9 --enable=ASYNC91 --disable=ASYNC910 would be possible to write and impossible to understand. Though that's ofc already the case when running as plugin
    • we could give a warning/error if users are using both enable+select or disable+ignore for ASYNC codes though

this would achieve:

  1. You can always use --enable to enable ASYNC9 codes, you're not forced to touch select/ignore
  2. Even if only using select/ignore you get the speed upside of disabling visitors (although this is somewhat diminished after adding ASYNC100 to Visitor91x)

Metadata

Metadata

Assignees

No one assigned

    Labels

    featureuser-facing improvement not directly related to a rule

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions