STY: migrate linting to ruff #4320
Conversation
neutrinoceros
force-pushed
the
migrate_to_ruff
branch
from
9ac5924 to
924d7e4
Compare
neutrinoceros
added
infrastructure
neutrinoceros
force-pushed
the
migrate_to_ruff
branch
from
924d7e4 to
d54c6fa
Compare
| @@ -1191,14 +1191,13 @@ def validate_object(obj, data_type): | |||
|
|
|||
| def validate_axis(ds, axis): | |||
| if ds is not None: | |||
| valid_axis = ds.coordinates.axis_name.keys() | |||
| valid_axis = sorted( | |||
| list(ds.coordinates.axis_name.keys()), key=lambda k: str(k).swapcase() | |||
There was a problem hiding this comment.
sorting keys. When sorting strings, uppercase comes before lower case, so I'm reverting that order with a custom lambda key to match how the default list ([0, 1, 2, "x", "y", "z", "X", "Y", "Z"]) is ordered.
There was a problem hiding this comment.
OK, so this is something you did to please the new linter but the old linter was OK with?
There was a problem hiding this comment.
Yes. Currently we rely on pyupgrade for this stuff, and it's documented as "timid" about string formatting. ruff is a little less so.
| desired = "Expected axis to be any of [0, 1, 2, 'x', 'y', 'z', 'X', 'Y', 'Z'], received 'r'" | ||
|
|
||
| actual = str(ex.exception) | ||
| assert actual == desired |
There was a problem hiding this comment.
did you manually change this? why?
There was a problem hiding this comment.
ruff automatically changed a couple strings originally formatted with the % operator to use the str.format method instead. I did a second, manual, pass to use fstrings instead and took the opportunity to slightly improve some affected error messages. Here I'm changing the test to match the -intentionally- updated message.
This is fine, but can you be explicit about what conditions should be met for you to be confortable with the migration ? |
|
I think when you will self-describe it as "Stable" rather than just "Used." I will confess also to having some linting/CI fatigue. I am trying to keep on top of things, but I also really want to see enhancements along other directions as well as linting, and it's hard to keep my mental energy pushing outwards along too many different vectors. So I guess that's what's coloring my ambivalence, but at the same time I don't want to just say no to a (mostly) no-op speedup. |
|
Perfectly understandable. I should clarify that what isn't stable is the API, which only affects writing additional code for ruff itself, but the user interface has been extremely stable for a project that hasn't reached version 0.1 yet.
Somewhat funnily, that's one of my reasons to want to migrate to ruff: it would drastically reduce the number of linting dependencies. I was also thinking, unrelated to ruff, that the time seemed ripe for us to slowdown the pace of pre-commit auto-updates (which I'm happy to do in a separate PR !) |
|
@matthewturk I'll dismiss your review so this doesn't get merged inadvertently. |
|
I forgot to adapt CONTRIBUTING.rst, switching to draft for now |
neutrinoceros
force-pushed
the
migrate_to_ruff
branch
4 times, most recently
from
5101d6a to
65e6ab6
Compare
neutrinoceros
force-pushed
the
migrate_to_ruff
branch
from
1f391a0 to
1058482
Compare
|
I'm coming around. What else would you like to happen? |
|
I would like @jzuhone to sign off since he also expressed reserves. |
|
I'm ok with this. |
PR Summary
Fix #4203
This brings
pre-commit run --all-filesdown to 5s on my machine (as opposed to 22s on the main branch), and pre-commit.ci runs complete in 30s instead of 60sruff is not completely stable yet but many big projects are already using it (pandas, scipy, jupyter, to name a few), and I wanted to see how big of an effort migration would actually be.
The patch I end up with is small enough to my taste that I feel confident to submit it for others to consider.
I discovered that ruff is slightly more agressive than pyupgrade on a couple rules, especially when it comes to replacing old string formatting (
%) with more modern equivalents, but even at the scale of our code base adoption appears straightforward !