Having flake8 extensions install at system level will break projects and there is no way to disable them
Here is a very simple to replicate use case, just install flake8-docstrings and now run flake8 on any project that was already using it.
You will have a change of over 99% to fail passing the flake8 tests, and there is no way to disable those plugins from inside the setup.cfg.
I raise a bug month than a month ago on flake8-docstrigs regarding this issue and got no reply at all, it seems that the project not maintained at all.
Assuming that that's not an isolated case we need a way to assure that the linting settings are locked within the setup.cfg, so the final result will not depend on whichever additional modules you may have installed on your system-modules.
I know that someone with inevitably try to propose a virtual environment with --no-site-packages but please remember that those are not always possible, there are several use-cases where people are forced to import system-packages (like on continous integration systems where you cannot afford to increase the footprint of each build with 500MB just because your projects is using numpy and pandas).
Flake8 needs an option to tell it to use a specific list of plugins and to ignore others.
Activity
Flake8 needs an option to tell it to use a specific list of plugins and to ignore others.
That would be using
selectandignoreto specify code prefixes, e.g.,D. Most plugins restrict themselves to a single namespace for all messages that they report (flake8-docstrings usesD, hacking usesH, etc.) so ignoring the ones you know you don't want in a certain project is simple. That said, you will need to also include all the error codes you expect to ignore.Since the release of 3.x.x version of flake8, this bug is not more valid than ever. Now we are forced to add "flake8<3.0.0" to almost any python project we encounter and that's not because flake8 introduced few fixable new issues.
The problem is that flake8 is now crashing in most of the cases due to the presence of different flake8 plugins.
flake8.exceptions.FailedToLoadPlugin: Flake8 failed to load plugin "P999" due to Plugin <module 'teamcity.flake8_plugin' from '/usr/local/lib/python2.7/site-packages/teamcity/flake8_plugin.pyc'> is not a callable. It might be written for an older version of flake8 and might not work with this version.It is unreasonable to assume that every plugin developer would update his plugin in order to make it work with flake8.
At this moment my impression is that is impossible to tell flake8 to ignore any plugins that may have already being installed on the system.
It is unreasonable to assume that every plugin developer would update his plugin in order to make it work with flake8.
We looked for incompatible plugins and all of the ones we found, were fixed and released by the authors (not all of whom are men).
At this moment my impression is that is impossible to tell flake8 to ignore any plugins that may have already being installed on the system.
This has never been the case. I think the case has been made for a
--disable-pluginsflag for a 3.1.0 or a 3.2.0 release or to add this behaviour to--isolated.Milestone changed to %3.x.0
@sigmavirus24 thanks for the update. I will try to gather more feedback as it will emerge from my attempt to convert over 20 repositories to use newer version of flask.
Milestone changed to %3.1.0
Milestone changed to %3.x.0
Mentioned in issue #253
Mentioned in issue #274 (closed)
Use of virtual environments does not solve the issue, imagine that we are running CI tests for validating compatibility with system installed packages (Python dependencies installed from RPMs instead of PIP). In fact pip usage is forbidden in such environment because it could mess the system configuration (overwriting packages installed from RPM).
