Ruff preview mode

[CoolCat467]

This pull request enables ruff's preview mode.

Currently a work in progress, but I wanted to see if I've messed anything up in the unit tests.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 99.58%. Comparing base (8850705) to head (ded5cac). Report is 38 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3024      +/-   ##
==========================================
- Coverage   99.58%   99.58%   -0.01%     
==========================================
  Files         121      121              
  Lines       18157    18155       -2     
  Branches     3272     3270       -2     
==========================================
- Hits        18082    18080       -2     
  Misses         52       52              
  Partials       23       23              

Files with missing lines	Coverage Δ
src/trio/_core/_entry_queue.py	100.00% <100.00%> (ø)
src/trio/_core/_tests/test_asyncgen.py	100.00% <100.00%> (ø)
src/trio/_core/_tests/test_instrumentation.py	100.00% <100.00%> (ø)
src/trio/_core/_tests/test_io.py	100.00% <100.00%> (ø)
src/trio/_core/_tests/test_mock_clock.py	100.00% <100.00%> (ø)
src/trio/_core/_tests/test_run.py	100.00% <100.00%> (ø)
src/trio/_dtls.py	97.50% <100.00%> (-0.01%)	:arrow_down:
src/trio/_socket.py	100.00% <ø> (ø)
src/trio/_subprocess.py	100.00% <100.00%> (ø)
src/trio/_tests/test_channel.py	100.00% <100.00%> (ø)
... and 21 more

[CoolCat467]

hash argument fixes being merged in this should fix what caused previous ci runs to fail

[A5rocks]

I was looking at whether ruff catches a forgotten prefix for fstrings like "hello {name}" and found RUF027. It seems to be under preview, so I'm for this change now! (at least for that specific lint, I'm not sure about everything else this has enabled since I haven't looked at the diff recently...)

[TeamSpen210]

Maybe we should enable explicit-preview-rules too. Then only rules we explicitly enable will be used. By definition preview rules might be incorrect, change, etc which would be bad if they suddenly start failing CI. Seems fine to run ruff ourselves when a new release comes out to try these rules though, most of the changes here are fine.

For these preview rules, we probably should disable ANN004 for now, since it produces false positives for all exceptiongroup imports. RUF029 (async functions without any await etc) should probably be disabled for test code. We don't particularly care about guaranteeing checkpoints there, and often we'll be implementing tasks that just assert/raise, without any async logic. Constantly disabling the rule is just distracting noise. Similarly ASYNC116, since we're using autojump it doesn't matter if sleeps are excessively long.

[CoolCat467]

There are no AN004s raised in trio when using the most recent version of ruff

[CoolCat467]

Going to merge this soon unless anyone has any additional concerns.

[TeamSpen210]

I think it would be good to merge the changes, but perhaps not actually enable preview-mode. By definition these rules are less certain, might have edge cases that don't work, or get reverted. So it'd be bad to update the pin, then suddenly have errors in CI that we might have to revert later. Instead just run them manually when there's a new version, see if we want to do anything at that point.

[A5rocks]

I think it would be good to merge the changes, but perhaps not actually enable preview-mode. By definition these rules are less certain, might have edge cases that don't work, or get reverted. So it'd be bad to update the pin, then suddenly have errors in CI that we might have to revert later. Instead just run them manually when there's a new version, see if we want to do anything at that point.

I think there are a few (like the fstring check rule) that would be nice to have, but maybe that's not worth the churn.

[CoolCat467]

I think it would be good to merge the changes, but perhaps not actually enable preview-mode. By definition these rules are less certain, might have edge cases that don't work, or get reverted. So it'd be bad to update the pin, then suddenly have errors in CI that we might have to revert later. Instead just run them manually when there's a new version, see if we want to do anything at that point.

That is a good point. What if instead, we specifically enabled all of the rules that are preview as of now, and then when new versions come out we can try adding the new ones then? Is it possible to do that with ruff?

[TeamSpen210]

Looks like you can't no. You can specify them, but it won't enable. But we could enable them in preparation.

[CoolCat467]

My current understanding of conversation is that it would be nice if we could specify which preview rules we would like to enable, but that is not possible as of writing. There was discussion about leaving the changes but not enabling preview mode, which I don't think would be a good solution because first if there are noqa lines for preview rule matches, then ruff's unused-noqa will get rid of them, and then we aren't checking future code against preview rules, leading to inconsistency. The idea behind leaving preview disabled is that new preview rules could be introduced which by definition are unstable and might not be good, but my counter is that we could always disable those specific new preview rules, but rightly said is that this will increase difficulty of updating ruff versions, but I don't think it would be too much of a hassle to disable said new rules if required.

Net result, I will continue with earlier stated merging, and in the event this is not the right course of action we can always revert this or apply a better solution on top of this.