Repository navigation
Having flake8 extensions install at system level will break projects and there is no way to disable them #488
Description
In GitLab by @ssbarnea on Apr 30, 2016, 14:27
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
asottile commentedon Apr 3, 2021
In GitLab by @sigmavirus24 on Apr 30, 2016, 14:39
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.asottile commentedon Apr 3, 2021
In GitLab by @ssbarnea on Aug 1, 2016, 06:31
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.
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.
asottile commentedon Apr 3, 2021
In GitLab by @sigmavirus24 on Aug 1, 2016, 07:38
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).
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.asottile commentedon Apr 3, 2021
In GitLab by @ssbarnea on Aug 1, 2016, 09:05
@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.
asottile commentedon Apr 3, 2021
In GitLab by @sigmavirus24 on Aug 1, 2016, 09:16
Actually instead of
--disable-pluginsI'm thinking of--whitelist-pluginswhich uses the plugin's name to filter out which plugins can run.asottile commentedon Apr 3, 2021
In GitLab by @ssbarnea on Aug 1, 2016, 13:06
indeed, whitelisting is much better! please also consider the case where plugin discovery exceptions can be ignored (non fatal). We had at least 2-3 in the last weeks.
asottile commentedon Apr 3, 2021
In GitLab by @wbolster on Aug 5, 2016, 02:47
i think installing flake8 in a virtualenv and never loading anything that's not in that virtualenv is the most sane approach. is that possible?
asottile commentedon Apr 3, 2021
In GitLab by @ssbarnea on Nov 24, 2016, 10:12
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).
asottile commentedon Apr 3, 2021
In GitLab by @asottile on Oct 2, 2020, 16:38
changed the description
Add --required-plugins and --allowed-plugins