Add more rules to `ruff` linter
Now we are using ruff, the idea is that we add more rules to ruff linter in separate PRs since there are a lot of fixes to do (maybe create a separate issues for that) . e.g.,
select = [
"I", # isort
"F", # pyflakes
"E", # pycodestyle errors
"W", # pycodestyle warnings
"N", # pep8-naming
"C90", # mccabe
"RUF", # Ruff-specific rules
"UP", # pyupgrade
"ERA", # eradicate
"PLC", # pylint - convention
"PLE", # pylint - error
"PLW", # pylint - warning
"A", # flake8-builtins
"B", # flake8-bugbear
"BLE", # flake8-blind-except
"C4", # flake8-comprehensions
"Q", # flake8-quotes
"G", # flake8-logging-format
"ICN", # flake8-import-conventions
"ISC", # flake8-implicit-str-concat
"PIE", # flake8-pie
"PTH", # flake8-use-pathlib
"RET", # flake8-return
"S", # flake8-bandit
"SIM", # flake8-simplify
"T10", # flake8-debugger
"T20", # flake8-print
"TCH", # flake8-type-checking
"TID", # flake8-tidy-imports
]
I think a good start would be to add support for:
- [ ] A (#4232)
- [ ] B
- [ ] N
- [ ] RUF
Originally posted by @emdneto in https://github.com/open-telemetry/opentelemetry-python/issues/4223#issuecomment-2409133880
Hi, I am an Outreachy applicant. May I work on this issue?
Thank you for assigning me this task.
When I added ruff rule A, I ran ruff check . as well. Should I fix them or do I keep adding the rules?
@Neema-Joju If the issues are easy to fix, I think you can open a PR adding rule "A" with the actual fixes so we can get more coverage from Ruff Linter.
@emdneto Ok. I'll create separate pull requests for different rules so, it will be easy for everyone to follow. As I work along I'll fix the issues that I can.
The list of rules in the description are huge.
Can we copy the most used rules from more modern projects from the ecosystem?
Pydantic: https://github.com/pydantic/pydantic/blob/f9f4aee799ceb65b25b2f95a3c030b7df2e929d1/pyproject.toml#L190-L208 FastAPI: https://github.com/fastapi/fastapi/blob/8c29eaec25b3add7106e1cbfe0c217e4bbd6f187/pyproject.toml#L188-L197 Starlette: https://github.com/encode/starlette/blob/ad7ff0800de563528691d26dcccf3c055cab0571/pyproject.toml#L56-L65
Also, related, but we can move away from pylint, like all modern projects? Since most of the rules are pedantic/redundant?
@Kludex, sure. The description is just a list of rules to see what's more suitable for us; we don't need to implement all of them. Would you be open to sending a PR adding the rules?
About pylint, I think we can drop pylint at some point when we are sure ruff is enough and we don't have pylint CI failing for a while
Happy to look at this at KubeCon 2025