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
flake8 supports multiple plugins. There are two methods under which these plugins - or rather, their checks - can be enabled. If a check is on-by-default then the mere process of installing the plugin is enough to enable it. Conversely, if a check is off-by-default then the user will need to enable it via their config file or equivalent CLI option. If a plugin is specifically enabled but flake8 fails to find it then flake8 will error out with FailedToLoadPlugin.
Under most circumstances, this is very sensible behavior: users should be installing flake8 and all required plugins in an environment, which users often accomplish using a test runner like tox or nox or something like pre-commit. However, when using flake8 with editors, things get trickier. There is currently no widespread machine-readable way of describing how to set up a linting environment specifically for a given project: while the flake8 configuration file can specify enabled plugins, it does not specify what packages they are provided by. Projects can specify their dependencies in a tox.ini or nox.py file, in .pre-commit-config.yaml file, in a requirements.txt, or many other places. They can also provide their own checks.
Because of the complexities inherent in creating environments, tools like ALE can't realistically script the creation of a linting environment and must rely on the users to create one. This is problematic in and of itself: if you don't install all of the plugins required by a project then flake8 will fail to run, but conversely if you install all of the plugins required by one project then any on-by-default checks provided by that plugin will run for all projects regardless of whether the project in question was actually designed for this. This means linting environment can't realistically be shared currently, but the non-scriptability of environments necessitates manual ad-hoc configuration and updating of environments on per-project basis, which clearly doesn't scale.
I'd like to propose a new CLI-only --ignore-missing-plugins flag. When specified, flake8 will no longer raise FailedToLoadPlugin if a plugin is specified in a configuration file but is not installed. Instead, it will proceed with the subset of available plugins. Alternatively, we could add a CLI-only --ignore-extensions flag that would disable all extensions except for those built into flake8. In both cases, the flag will allow users to fallback to a default, system-wide flake8 installation in the absence of a project specific linting environment. While this will not be perfect - it doesn't account for flake8 version mismatches and users will obviously not see any potential warnings for checks provided by plugins - it does allow users to use the default linters provided by flake8 inside their editor which are, if we're being honest, generally the most important linters of the bunch.
I'd be happy to take a shot at adding this flag and at first pass it seems it would be relatively easy to do, but I'd like to sanity-check the idea before I write any code or tests.
The text was updated successfully, but these errors were encountered:
describe the request
flake8 supports multiple plugins. There are two methods under which these plugins - or rather, their checks - can be enabled. If a check is on-by-default then the mere process of installing the plugin is enough to enable it. Conversely, if a check is off-by-default then the user will need to enable it via their config file or equivalent CLI option. If a plugin is specifically enabled but flake8 fails to find it then flake8 will error out with
FailedToLoadPlugin
.Under most circumstances, this is very sensible behavior: users should be installing flake8 and all required plugins in an environment, which users often accomplish using a test runner like tox or nox or something like pre-commit. However, when using flake8 with editors, things get trickier. There is currently no widespread machine-readable way of describing how to set up a linting environment specifically for a given project: while the flake8 configuration file can specify enabled plugins, it does not specify what packages they are provided by. Projects can specify their dependencies in a
tox.ini
ornox.py
file, in.pre-commit-config.yaml
file, in arequirements.txt
, or many other places. They can also provide their own checks.Because of the complexities inherent in creating environments, tools like ALE can't realistically script the creation of a linting environment and must rely on the users to create one. This is problematic in and of itself: if you don't install all of the plugins required by a project then flake8 will fail to run, but conversely if you install all of the plugins required by one project then any on-by-default checks provided by that plugin will run for all projects regardless of whether the project in question was actually designed for this. This means linting environment can't realistically be shared currently, but the non-scriptability of environments necessitates manual ad-hoc configuration and updating of environments on per-project basis, which clearly doesn't scale.
I'd like to propose a new CLI-only
--ignore-missing-plugins
flag. When specified, flake8 will no longer raiseFailedToLoadPlugin
if a plugin is specified in a configuration file but is not installed. Instead, it will proceed with the subset of available plugins. Alternatively, we could add a CLI-only--ignore-extensions
flag that would disable all extensions except for those built into flake8. In both cases, the flag will allow users to fallback to a default, system-wideflake8
installation in the absence of a project specific linting environment. While this will not be perfect - it doesn't account for flake8 version mismatches and users will obviously not see any potential warnings for checks provided by plugins - it does allow users to use the default linters provided by flake8 inside their editor which are, if we're being honest, generally the most important linters of the bunch.I'd be happy to take a shot at adding this flag and at first pass it seems it would be relatively easy to do, but I'd like to sanity-check the idea before I write any code or tests.
The text was updated successfully, but these errors were encountered: