Proposal: use ruff to replace flake8 and related extensions

[cauliyang]

Now ruff is blazing fast linter than flake8. Its rules are self contained and it is evolving quickly so far. Currently it has covered most useful rules. I think we can keep an eye on it and move to ruff at proper time. What do you think?

[joelb123]

I strongly agree. Not only is it faster, the list of modules that would get replaced, AFAIK is:

• bandit
• flake8-bugbear
• flake8-docstrings
• flake8-rst-docstrings
• isort
• pep8-naming
• pydocstyle
• pyupgrade

In addition, there's more out-of-the-box functionality (e.g. pandas-vet for us pandas users).

[bmritz]

@joelb123 @cauliyang do you know of any forks that use ruff? I have a fork at https://github.com/bmritz/cookiecutter-hypermodern-python that I was thinking about putting ruff into, but if there's a reference I could go off of, that would be helpful.

EDIT: here's one: https://github.com/dbatten5/cookiecutter-hypermodern-python. And here is the relevant commit: https://github.com/dbatten5/cookiecutter-hypermodern-python/commit/327b373ce1ffbb1ebfb13e9d3fa8b48a4fafe271

[joelb123]

Yes, I saw the @dbatten5 commit, but I haven't looked at it in detail. I did notice that this fork kept 'isort', which is a pity since getting rid of fighting with 'isort' is one of the many good things about ruff.

Because ruff is so performant and has '--fix' for many issues, it can enable checks/fixes with every save by the IDE (e.g., via the pycharm ruff plugin). This means more productivity for those who use ruff, but it also means more boilerplate in 'pyproject.toml'.

[dbatten5]

I couldn't really get ruff working without isort the same as when I had isort. Would be happy to get rid of it though and run everything through ruff - do you have an example config for ruff replacing the need for isort @joelb123 ?

EDIT: Got there in the end https://github.com/dbatten5/cookiecutter-hypermodern-python/commit/68dbd7d52e6215119aa6428f472b1ee44603c009 . Was having a little trouble with autodetection of first party imports so ended up having to go with src = ['src', 'tests'] under [tool.ruff].

[bosd]

Does anyone have ruff running succesfully and able to open a PR in this repo?

[dbatten5]

I have it running in my fork https://github.com/dbatten5/cookiecutter-hypermodern-python. Should be able to open a PR in the near future

[aeturrell]

I think this would be a great change, not sure if anyone has put in a PR for it yet?

[bruno-fs]

I'm working on replacing all compatible linters with ruff on my fork. The only things I didn't replace yet are darglint and flake8-rst-docstrings. I'm not sure how to handle them. I also replaced black with ruff format.

Given darglint was archived, I wonder if it is still relevant. But there's an open issue for it on ruff repo. However, flake8-rst-docstrings don't have an open discussion there.

[webknjaz]

There's darglint2 per https://softwarerecs.stackexchange.com/a/86925/61183, additionally, there's a pylint plugin with similar features. There's a similar flake8 integration in https://github.com/jsh9/pydoclint which is promised to be faster. The latter was actually offered in the issue mentioned above.

[bruno-fs]

@webknjaz Thanks for pointing that out! I'm impressed with pydoclint speed!

[bosd]

@bruno-fs Your fork looks really interesting. Any plans to contribute and open a PR here? 🙏

[bruno-fs]

Thanks, @bosd. I'm using it in some projects.

I do plan to open a PR, but aaaaaaaaaall the documentation still needs to be updated and I have other priorities atm.

Also, I went a little bit further and stripped away flake8-rst-docstrings and replaced darglint with pydoclint, which might be seem as controversial moves.

Furthermore, I'm also on the verge of removing poetry.lock from the template, because it is a constant source of conflicts in my workflow, which relies on cruft .

[bosd]

@bruno-fs Thanks, your fork looks really interesting. Specifically the cruft. Personally I like it, but it might be too opinionated for the projects i'm working with.

[bruno-fs]

@bosd cruft is not on the fork, I'm just using it to consume the template instead of using cookiecutter itself :D

But replacing linters with ruff already is an opinionated move. The author might not even accept a PR. What are your thoughts on this matter, @cjolowicz?

Would you accept a PR replacing python linters with ruff? If so, I could create a branch with a cleanup version of my fork, only replacing the linters. I'd probably need help from someone interested to also update the documentation. That part is lacking in my fork.