Repository navigation
select/ignore/enable/disable is a mess #260
Copy link
Copy link
Open
Labels
featureuser-facing improvement not directly related to a ruleuser-facing improvement not directly related to a rule
Description
Status quo:
ignoreorextend-ignoreASYNC error codes in config is not possible, as flake8 gives an error- when running flake8-async as a plugin,
--ignoreand--extend-ignoreis possible on the command-line, flake8 does not seem to enforce the three-letter rule there selectdoes not currently have the validation rules enabled thatignoredoes.--selectand--ignoreare not supported when running as standalone- it's always possible to use
--enableand--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
--disabletoASYNC9.
Implications:
- if running as plugin, you have to
select/--selectASYNC9xx codes to enable them. Trying toenablethem will do nothing. - But if you want to default-enable ASYNC9xx rules, and disable them individually, you need to use a combination of
select/--selectand--disable(or--ignoreon the CLI). - if running as standalone, you have to
--enableASYNC9xx codes.--selectgives 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:
- Stop calling
option_manager.extend_default_ignore - Always default
--disabletoASYNC9 - in
parse_options, readoptions.selectand parse out any selectedASY...codes, adding them to--enable - same thing with
options.ignore->--disable, in case--ignorehas been used on the CLI - [maybe] register
--selectand--ignoreas 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=ASYNC910would 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 make it slightly easier to switch from plugin to standalone, but the added complexity might not be worth it. e.g.
this would achieve:
- You can always use
--enableto enable ASYNC9 codes, you're not forced to touch select/ignore - Even if only using select/ignore you get the speed upside of disabling visitors (although this is somewhat diminished after adding ASYNC100 to Visitor91x)
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
featureuser-facing improvement not directly related to a ruleuser-facing improvement not directly related to a rule
Activity