You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A hook woud accept the parsed_config dict, and then return a new or modified dict that is used by the subsequent codepath. The approach would preserve (and further solidify) the status quo that command line options take precedence over parsed config values (whatever their origin). This approach also seems minimally invasive to the current codebase.
I believe this feature would a number of benefits to flake8 users and developers:
Easy to explain semantics: A config hook accepts the standard flake8 parsed config, and may modify it or replace it.
Affords a path to self-service for users wanting to configure flake8 by other mechanisms (e.g. database, API, env vars, secrets stores, or other files) that avoids burdening flake8 developers with commitments for use-cases that are too niche or new.
Is the implementation outline above technically sound from a high level perspective? If so, would a Pull Request for this feature be considered?
The text was updated successfully, but these errors were encountered:
describe the request
Currently
flake8
recognizes two entry points for plugins:flake8.extension
flake8.report
I would like to propose adding a new plugin hook
flake8.configuration
for intercepting and processing flake8 configuration options.It seems that a configuration hook (if present) should be applied here:
flake8/src/flake8/options/aggregator.py
Line 29 in 6027577
A hook woud accept the
parsed_config
dict, and then return a new or modified dict that is used by the subsequent codepath. The approach would preserve (and further solidify) the status quo that command line options take precedence over parsed config values (whatever their origin). This approach also seems minimally invasive to the current codebase.I believe this feature would a number of benefits to
flake8
users and developers:flake8
by other mechanisms (e.g. database, API, env vars, secrets stores, or other files) that avoids burdeningflake8
developers with commitments for use-cases that are too niche or new.Is the implementation outline above technically sound from a high level perspective? If so, would a Pull Request for this feature be considered?
The text was updated successfully, but these errors were encountered: