Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add option to ignore missing plugins/disable all plugins #1843

Closed
stephenfin opened this issue Jul 13, 2023 · 2 comments
Closed

Add option to ignore missing plugins/disable all plugins #1843

stephenfin opened this issue Jul 13, 2023 · 2 comments

Comments

@stephenfin
Copy link
Contributor

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 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.

@asottile
Copy link
Member

please read the issue template and search the issue tracker for duplicates next time !

@stephenfin
Copy link
Contributor Author

My bad. This is covered by #751 and #488. Seems like the idea is feasible so, which is what I wanted to know. I'll take a look.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants