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

Guard type hinting via ruff #166

Merged
merged 5 commits into from
Aug 2, 2024

Conversation

notatallshaw
Copy link
Contributor

This PR builds on top of #165

I notice it's a common pattern in this library, and one I prefer, to use from __future__ import annotations and guard type hint only imports behind if TYPE_CHECKING, this can be implemented automatically with ruff using: required-imports = ["from __future__ import annotations"] with the isort rules and the TCH rules: https://docs.astral.sh/ruff/rules/#flake8-type-checking-tch (namely TCH001, TCH002, and TCH003).

I updated the config than then just ran a series of ruff --fix commands for the remaining commits (I have documented them to be clear).

Let me know if this is to your liking or not.

pyproject.toml Outdated
@@ -97,7 +98,7 @@ exclude = [
]

[tool.ruff.lint.isort]
known-first-party = ["resolvelib"]
required-imports = ["from __future__ import annotations"]

Choose a reason for hiding this comment

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

There's also the FA rules, which might make this setting redundant :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In the past I found FA rules didn't always enable from __future__ import annotations when I expected, but looking at this PR it seems like all the additional from __future__ import annotations aren't stictly necessary.

I've updated to use FA instead, it makes the PR a lot less noisey. Thanks.

@notatallshaw
Copy link
Contributor Author

notatallshaw commented Aug 1, 2024

FYI, this actually appears to catch a bug by correctly moving RequirementsConflicted out of the TYPE_CHECKING block in tests/test_resolvers.py, as it used in an exception catch.

It seems like no test case is triggering this test code path, if no one else does I will take a look in the coming weeks.

@frostming frostming merged commit b45601d into sarugaku:main Aug 2, 2024
9 checks passed
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.

4 participants