-
Notifications
You must be signed in to change notification settings - Fork 24
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
Use ruff instead of flake8 #79
Conversation
gaborbernat
commented
Jun 16, 2023
- Fix broken issue link and bump tools
- Use ruff instead of flake8
Signed-off-by: Bernát Gábor <[email protected]>
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.
As far as I can tell, you've got a mix of manual changes and automatically generated changes, as well as functional changes and stylistic changes, all rolled into a single commit. This is really hard to review. Can you please do separate commits for each logical change?
@@ -1,13 +1,16 @@ | |||
"""Sphinx configuration file for pytest-memray documentation.""" | |||
"""Sphinx configuration file for pytest-memray documentation.""" # noqa: INP001 |
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.
Mm. It doesn't have any provision for handling scripts that aren't part of packages? That's annoying...
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.
All python files should be formatted, I don't see why this should be different.
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.
I think you misunderstood me. I'm not arguing that docs/conf.py
shouldn't be formatted, I'm complaining that ruff
thinks that docs
is a Python package, and wants is to create a docs/__init__.py
- it doesn't understand that docs/conf.py
is a standalone script that's not part of any package.
if TYPE_CHECKING: | ||
from sphinx.application import Sphinx |
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.
Why does this need to be moved below an if TYPE_CHECKING:
?
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.
Done automatically by ruff, read https://beta.ruff.rs/docs/rules/typing-only-first-party-import/
here = Path(__file__).parent | ||
root, exe = here.parent, Path(sys.executable) | ||
towncrier = exe.with_name(f"towncrier{exe.suffix}") | ||
cmd = [str(towncrier), "build", "--draft", "--version", "NEXT"] | ||
new = check_output(cmd, cwd=root, text=True) | ||
new = check_output(cmd, cwd=root, text=True) # noqa: S603 |
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.
We should probably ignore this rule globally. I have no idea what it's complaining about.
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.
I think locally is better to be explicit that this instance is allowed but not in general. https://beta.ruff.rs/docs/rules/#flake8-bandit-s shows the rules with explanation.
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.
Yes, I read the rule explanation. It seems to complain about every call to subprocess
, as far as I can see. I tested running it with cmd
set to a list of hardcoded strings, and it still raised an S603 error. That doesn't seem useful to me - have I missed something?
@@ -1,18 +1,18 @@ | |||
from __future__ import annotations | |||
from __future__ import annotations # noqa: INP001 |
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.
If this is in docs/
, it's intended for end-user consumption, right? Not just for maintainers? If so, I don't think we should add annotations here to appease our linter. I think we should tell the linter to ignore this file instead.
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.
I don't agree. Why should not we lint documentation files same as the rest?
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.
Because it makes the code harder to read by adding annotations that most of our users won't recognize or care about, which makes it function worse as documentation
readme.content-type = "text/markdown" | ||
readme.file = "README.md" |
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.
Why was this line moved? Did a tool do this automatically?
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.
Indeed used https://github.com/tox-dev/pyproject-fmt
"version", | ||
] | ||
dependencies = [ | ||
"memray>=1.8", |
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.
Why are we changing from depending on memray >=1.5 to >=1.8? Is this something that should have already been applied in the past and was missed? If so, can you at least make it a separate commit so we can find it when searching through the git log?
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.
Because the CI is only testing the latest version of memray. Anything else is a guess at best, and a straight lie otherwise. We might as well be explicit about what version we support (aka test with). Explicit better than implicit.
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.
OK, fine. This should be done in a separate commit, so that your reviewer doesn't need to guess what changes were made automatically by a tool and what changes were made manually by you.
Nope, all was done automatically; minus a very few that ruff required to pass. |
It's very, very difficult to review this when all in one commit lines have been moved and changed, with some changes having been done manually and others having been done by automated tools. I'd like at least 4 separate commits here:
Plus separate commits for any other manual changes I didn't notice. |
Let's forget it, too much effort. I'll spend my effort on other projects. |
Thanks for the review though 🙏 |