FlakeHell was archived

Sorry, flakehell was archived. it was my the most mentally difficult project, and I don’t maintain it anymore. Probably, the WPS documentation should be adjusted accordingly, removing flakehell references. I don’t insist, though 😃

Luckily, the documentation already has a great section about flake8 --diff which should be enough for most of the cases from the perspective of integrating WPS with a big codebase. Additionally, I can recommend:

1. reviewdog which supports flake8 out of the box and by default filters violations only for the diff,
2. GitLab code quality report which shows only violations that are new in the analyzed merge request. There are few flake8 plugins to generate the report: flake8-gl-codeclimate (I used it, works pretty well) and flake8-codeclimate.

[Dreamsorcerer]

We also have #1276 and #1471, which will hopefully make it into 0.16 (flakehell is already removed from the documentation in that first PR).

I’ve been using that branch for a few months locally now, and it works pretty well.

[Dreamsorcerer]

Not sure if I understand what you’re talking about. At a scale of one hundred thousand lines, flakehell/flakeheaven works quite well, and in terms of performance it is comparable to directly running wemake-python-styleguide through the flake8 command.

Not if you install plugins. I think the performance issue may have been atleast partially resolved, but to support the granular controls over enabling/disabling error codes (not something we even wanted to use) it was basically rechecking the code several times or something. So, the performance of flake8 is O(n), while the performance of flakehell is more like O(nm), where n is number of files and m is number of plugins (or something along those lines, it’s been awhile). On our project flake8 was taking ~2 minutes to run, while flakehell was taking over 30 minutes (I literally gave up and cancelled it after 30 minutes). That included wemake and several other flake8 plugins on ~30k lines of code.

What problems there might be with multiple developers, I can’t imagine at all. I personally implemented linters through flakehell/flakeheaven on several legacy projects in different companies, and in all cases, the feedback from colleagues was positive.

Fair enough. To me, the feature was sufficiently rudimentary that it seemed too cumbersome to use. e.g. Changes frequently result in far too many baseline exceptions reappearing in the output and not being ignored anymore (even from trivial changes). I was using my branch at my last company, and it was working a lot better. The matching behaviour results in much less previously ignored exceptions reappearing, it updates the baseline after your changes (to avoid multiple small changes reintroducing ignored exceptions), and removes anything from the baseline that is no longer in the code (to avoid accidentally ignoring new exceptions).