Skip to content
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

Closed
wants to merge 1 commit into from
Closed

Conversation

gaborbernat
Copy link
Contributor

  • Fix broken issue link and bump tools
  • Use ruff instead of flake8

@gaborbernat gaborbernat changed the title ruff Use ruff instead of flake8 Jun 16, 2023
Signed-off-by: Bernát Gábor <[email protected]>
Copy link
Contributor

@godlygeek godlygeek left a 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
Copy link
Contributor

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...

Copy link
Contributor Author

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.

Copy link
Contributor

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.

Comment on lines +11 to +12
if TYPE_CHECKING:
from sphinx.application import Sphinx
Copy link
Contributor

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:?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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
Copy link
Contributor

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.

Copy link
Contributor Author

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?

Copy link
Contributor

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"
Copy link
Contributor

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"version",
]
dependencies = [
"memray>=1.8",
Copy link
Contributor

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?

Copy link
Contributor Author

@gaborbernat gaborbernat Jun 17, 2023

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.

Copy link
Contributor

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.

pyproject.toml Show resolved Hide resolved
@gaborbernat
Copy link
Contributor Author

gaborbernat commented Jun 17, 2023

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.

Nope, all was done automatically; minus a very few that ruff required to pass. ruff check --fix automatically applies most of the changes, hard to separate them out 🤷 and probably not worth the effort.

@godlygeek
Copy link
Contributor

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:

  1. The configuration changes to start using ruff instead of flake8 and isort
  2. The changes automatically made by ruff check --fix
  3. The changes automatically made by pyproject-fmt
  4. The changes manually made to the versions of our declared dependencies

Plus separate commits for any other manual changes I didn't notice.

@gaborbernat
Copy link
Contributor Author

gaborbernat commented Jun 17, 2023

Let's forget it, too much effort. I'll spend my effort on other projects.

@gaborbernat gaborbernat deleted the ruff branch June 17, 2023 01:26
@gaborbernat
Copy link
Contributor Author

Thanks for the review though 🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants