search

adfinis / timedctl

GNU Affero General Public License v3.0
5 stars 0 forks source link

Re-evaluate ruff #15

Closed gianklug closed 1 year ago

gianklug commented 1 year ago

Ruff is nice and fast but currently pylint catches way more issues than ruff. See the following GitHub issue as an example: https://github.com/astral-sh/ruff/issues/689

Should we just go for both and only let pylint run on PRs?

@hairmare maybe you can share your opinion here?

hairmare commented 1 year ago

personally i decided that pylint just isn't worth the wait in most cases, ruff might not (yet) have 100% the same coverage but it has --fix and is a modern solution that was built-for and not ported-to Python 3. Another reason was that my pylint configs were getting bloated over time with more plugins and this was bogging down my pytest runs.

btw, ruff is moving quickly, https://github.com/astral-sh/ruff/issues/970 is inching closer towards having implemented half of pylints test's and it's not looking like they are loosing steam

i do understand wanting to run both, in your cases. I still do so in some cases as well, ie. when i'm analyzing a legacy code base i'll use pylint locally to get a first impression. In the cases where i exclusively use it the project usually also has a test coverage of 100%, is pythonic from the get-go, and has at least started having types hints as well.

oh, and i only run ruff (and pytest for that matter) on pull requests to main, not on push because that makes jobs run twice for no good reason while rarely providing much in addition to the pr run..

gianklug commented 1 year ago

I guess we'll keep on using ruff then but just on PRs. Implementing all the PEPs that aren't in ruff yet but pylint detects just eat time to fix.

I'll close this as soon as the CI is adjusted.