Skip to content

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

Open

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)

Activity

  1. added
    featureuser-facing improvement not directly related to a rule
    on Mar 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

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