-
Notifications
You must be signed in to change notification settings - Fork 5
misc: [DPE-7961] new linting rules #286
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Original file line number | Diff line number | Diff line change | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
@@ -32,20 +32,20 @@ opentelemetry-exporter-otlp-proto-http = "1.21.0" | |||||||||||||||
optional = true | ||||||||||||||||
|
||||||||||||||||
[tool.poetry.group.format.dependencies] | ||||||||||||||||
ruff = "^0.12.4" | ||||||||||||||||
ruff = "^0.12.7" | ||||||||||||||||
|
||||||||||||||||
[tool.poetry.group.lint] | ||||||||||||||||
optional = true | ||||||||||||||||
|
||||||||||||||||
[tool.poetry.group.lint.dependencies] | ||||||||||||||||
ruff = "^0.12.4" | ||||||||||||||||
ruff = "^0.12.7" | ||||||||||||||||
codespell = "^2.4.1" | ||||||||||||||||
|
||||||||||||||||
[tool.poetry.group.unit.dependencies] | ||||||||||||||||
pytest = "^8.4.1" | ||||||||||||||||
pytest-xdist = "^3.8.0" | ||||||||||||||||
pytest-cov = "^6.2.1" | ||||||||||||||||
ops-scenario = "^6.0.3, <6.0.4" # 6.0.4 requires ops >= 2.12 | ||||||||||||||||
ops-scenario = "^6.0.3, <6.0.4" # 6.0.4 requires ops >= 2.12 | ||||||||||||||||
|
||||||||||||||||
[tool.poetry.group.integration.dependencies] | ||||||||||||||||
pytest = "^8.4.1" | ||||||||||||||||
|
@@ -84,23 +84,47 @@ line-length = 99 | |||||||||||||||
|
||||||||||||||||
[tool.ruff.lint] | ||||||||||||||||
explicit-preview-rules = true | ||||||||||||||||
select = ["A", "E", "W", "F", "C", "N", "D", "I", "CPY001"] | ||||||||||||||||
select = [ | ||||||||||||||||
"A", | ||||||||||||||||
"E", | ||||||||||||||||
"W", | ||||||||||||||||
"F", | ||||||||||||||||
"C", | ||||||||||||||||
"N", | ||||||||||||||||
"D", | ||||||||||||||||
"I", | ||||||||||||||||
"B", | ||||||||||||||||
"CPY001", | ||||||||||||||||
"RUF", | ||||||||||||||||
"S", | ||||||||||||||||
"SIM", | ||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
imo, many of these rules decrease readability of the code There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 👋🏻 My 2 cents about this topic is that the SIM linting rule should not stay, as some of the rules enforce syntax that we may not want to apply, either for readability purposes, or because we want to sneak a comment right in the middle of two statements. It it up to you if you want to fine-tune the rules and select only those that are overwhelmingly benign (i.e. double-negation, expr-with-true-false...) |
||||||||||||||||
"UP", | ||||||||||||||||
"TC", | ||||||||||||||||
] | ||||||||||||||||
ignore = [ | ||||||||||||||||
# Missing docstring in public method (pydocstyle doesn't look for docstrings in super class | ||||||||||||||||
# https://github.com/PyCQA/pydocstyle/issues/309) TODO: add pylint check? https://github.com/PyCQA/pydocstyle/issues/309#issuecomment-1284142716 | ||||||||||||||||
"D102", | ||||||||||||||||
"D105", # Missing docstring in magic method | ||||||||||||||||
"D107", # Missing docstring in __init__ | ||||||||||||||||
"D403", # First word of the first line should be capitalized (false positive on "MySQL") | ||||||||||||||||
"D415", # Docstring first line punctuation (doesn't make sense for properties) | ||||||||||||||||
"E501", # Line too long (because using black creates errors with this) | ||||||||||||||||
"N818", # Exception name should be named with an Error suffix | ||||||||||||||||
"W505", # Doc line too long (so that strings in comments aren't split across lines) | ||||||||||||||||
# Missing docstring in public method (pydocstyle doesn't look for docstrings in super class | ||||||||||||||||
# https://github.com/PyCQA/pydocstyle/issues/309) TODO: add pylint check? https://github.com/PyCQA/pydocstyle/issues/309#issuecomment-1284142716 | ||||||||||||||||
"D102", | ||||||||||||||||
"D105", # Missing docstring in magic method | ||||||||||||||||
"D107", # Missing docstring in __init__ | ||||||||||||||||
"D403", # First word of the first line should be capitalized (false positive on "MySQL") | ||||||||||||||||
"D415", # Docstring first line punctuation (doesn't make sense for properties) | ||||||||||||||||
"E501", # Line too long (because using black creates errors with this) | ||||||||||||||||
"N818", # Exception name should be named with an Error suffix | ||||||||||||||||
"W505", # Doc line too long (so that strings in comments aren't split across lines) | ||||||||||||||||
"S101", | ||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. charms aren't run with I think asserts are valuable for
I think adding s101 will result in less assumptions getting documented (an assert is much cheaper than if: raise) yes we should raise exceptions (and not assert) for expected errors, but I don't think we should get rid of assert for documenting assumptions ctrl-f "assert" in https://github.com/canonical/charm-refresh/blob/main/charm_refresh/_main.py for some examples of things I wouldn't bother writing code to raise an exception for but is worth writing an assert to document the assumption There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. My 2 cents is that asserts in production code is weird, due:
Short code is not something to pursue and I disregard it as a good argument. We should pursue being explicit instead.
Being explicit does a better job and, There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
imo we should never be catching asserts—if we're catching, a proper exception should be raised
I think it's significantly more readable and, practically speaking, the alternative would be to not document assumptions at all instead of raising exceptions There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 👋🏻 My 2 cents about this topic is that we should avoid using assertions. I agree that the assertions are shorten than properly defined + raised exceptions, but I think we should strive for the latter and do not take shortcuts. Both the name and doc-string of the substitute exceptions will replace the documentation value of the assertions, possibly even surpassing it. In short: I am in favor of applying There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
b011 for same reason as s101 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 👋🏻 My 2 cents here highly varies from rule to rule: |
||||||||||||||||
] | ||||||||||||||||
|
||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
change behavior of ruf031 to be more readable |
||||||||||||||||
[tool.ruff.lint.per-file-ignores] | ||||||||||||||||
# D100, D101, D102, D103: Ignore missing docstrings in tests | ||||||||||||||||
"tests/*" = ["D1"] | ||||||||||||||||
"tests/*" = [ | ||||||||||||||||
"D1", | ||||||||||||||||
"D417", | ||||||||||||||||
# Asserts | ||||||||||||||||
"B011", | ||||||||||||||||
# Disable security checks for tests | ||||||||||||||||
"S", | ||||||||||||||||
] | ||||||||||||||||
|
||||||||||||||||
[tool.ruff.lint.flake8-copyright] | ||||||||||||||||
# Check for properly formatted copyright header in each file | ||||||||||||||||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks like this causes a lot of false positives, don't think it's worth the hassle
e.g. https://github.com/search?q=repo%3Acanonical%2Fmysql-operator%20s105&type=code
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👋🏻 My 2 cents about this topic is that the
S
linting rule should stay, as there are a bunch of security related misconfigurations it could detect. I recognizeS105
is annoying, but I think the benefits outweigh the drawbacks.