FlakeHell was archived #1817

Open orsinium opened 3 years ago

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:

reviewdog which supports flake8 out of the box and by default filters violations only for the diff,
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.

@orsinium thanks for working on it! 👍

No, thank you for your help with the project. You made it possible in the first place :)

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 awesome! Do you have some time to polish it? I would love to get it merged! 👍

BTW, today I was contacted by a team that used flakehell and they decided to maintain a fork:

https://github.com/flakehell/flakehell

So, maybe it will have a second life, we'll see. Anyway, I'll be happy if WPS becomes self-contained in that sense. Or, even better, baseline finally lands into flake8 itself. We already have at least two independent implementations that work, so why not.

@Dreamsorcerer awesome! Do you have some time to polish it?

Possibly, yes. But, will need you to take a look and review first.

I no longer need the baseline functionality, so don't plan to do further development on it. However, the PR is still ready for review, and I'm happy to answer any questions about the code.

I think it is good enough for a public release, but with a few ideas that could be implemented to improve future releases (in particular see https://github.com/wemake-services/wemake-python-styleguide/pull/1276#issuecomment-646757232 and the disabled all_change test: https://github.com/wemake-services/wemake-python-styleguide/pull/1471/files#diff-d0914f16c784a2349a4008ccc24c17220012a08741e8c54f290c74dd488efaa1R148).

@Dreamsorcerer thanks a lot for your time and effort! 👍

I am working on another static analysis tool where I consider "baseline" as a core feature. I am not sure that I will ever add such a complex thing into wps, maybe as a 3rd-party plugin.

I would add that flakehell has a community-maintained fork flakehaven. Maybe instead of deleting all mentions, we can replace them with flakehaven and thus support the project?

I suspect the baseline functionality is still very rudimentary (as in, it will just be too awkward to actually use in a real project with multiple developers). And if they've still not fixed the glaring performance issues, then it would still be totally unusable in my projects (edit: actually, looks like it may have been looked at). I think my closed PR is still much further along with regards to baseline functionality.

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.

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.

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

wemake-services / wemake-python-styleguide

FlakeHell was archived #1817