Namcap: enable ruff's isort rule
Start with enabling ruff linting rules, the isort rule is an autofix.
Merge request reports
Activity
I'm definitely in favor here, but given that these changes are auto-generated I'm inclined to get !52 (merged) and maybe some of the other open MRs with any significant code surface area merged first, then update this with regenerated fixes. I realize it can be done the other way around by manually applying the changes and appending them to the other MRs, but it makes rebasing them for a flat history quite a bit more complicated. If we can get some review progress on anything we feel like is close to being ready I'll come back to this as soon as they get merged.
That's kind of what I figured. My current plan is to merge this last-thing before cutting the next release, which will probably be a small patch release motivated by #72, which means landing !56 (merged) (and maybe !53 (merged)) and then this. Whether or not some typechecking from !41 (merged) lands first depends on review and testing status there, I'm actually kind of inclined to leave that for just after a patch release so it gets better testing while being in Git HEAD a while before a release.
added 41 commits
-
8872a32b...9129a77f - 40 commits from branch
pacman:master - 173bd27f - Namcap: enable ruff's isort rule
-
8872a32b...9129a77f - 40 commits from branch
