Closed A5rocks closed 2 months ago
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 99.63%. Comparing base (
b4c19bc
) to head (229c76b
).
Yikes looks like GHA sometimes makes macos-latest
use the new m1 chips even though setup python doesn't like that: https://github.com/A5rocks/trio/actions/runs/8827503948/job/24234861793
If
ruff
doesn't run ingen_exports
, that's ... fine. We have CI jobs dedicated to checking our code is alright and if it isn't, then that will be caught. Removing that is another PR's job though.
I think running ruff in gen_exports
is important, now that ruff handles import sorting, and if it isn't run then ruff will complain about generated files. I remember working on exactly this at one point.
Doesn't look like this loses test coverage. Removing test_run_ruff
probably does though, and removing test_lint_failures
definitely does. (but I'd argue that coverage loss is beneficial.)
For clarity, when I say "If ruff
doesn't run in gen_exports
, that's ... fine." I mean "if we break it accidentally" (which is the case the tests guard against).
https://github.com/python-trio/trio/pull/2988 was closed, but I think we agree that
test_run_black
can be removed. I don't actually remember why it was introduced, but using blame all the way back leads to it not seeming necessary. It was made becausetest_lint_failure
wouldn't check thatruff
was actually running, so we duplicated that to have ablack
-specific test and aruff
-specific test. Theruff
one is still useful (maybe), but theblack
one is duplicated.I'm not so sure any of these tests should exist anymore. I think I kinda pushed for the
ruff
-specific one but now I think it's ultimately unnecessary. Ifruff
doesn't run ingen_exports
, that's ... fine. We have CI jobs dedicated to checking our code is alright and if it isn't, then that will be caught. Removing that is another PR's job though.