Why
.pre-commit-config.yaml and CI both run ruff unpinned:
- id: ruff-check
entry: uvx ruff check .
and the repo carries no ruff configuration, so the rule set is whatever that day's ruff calls its default. That default is not a stable contract. Ruff 0.16.4 widened it from roughly 60 rules to 413, and a tree that had been green went red on 31 findings in code nobody had touched:
| rule |
count |
PLW1510 subprocess-run-without-check |
23 |
TRY004 type-check-without-type-error |
3 |
EXE001 shebang-not-executable |
3 |
SIM102 collapsible-if |
1 |
DTZ011 call-date-today |
1 |
Because ruff-check is the first pre-commit hook, this blocked every commit in the repository, including one whose own five checks were otherwise green. Under ruff's historical default set (E4, E7, E9, F) the tree passes cleanly, so nothing in the code regressed — only the question being asked of it changed.
Found while committing #59, which is the same failure one level up: a rule whose meaning depends on the reader's environment rather than being written down. #59 fixed it for the coding standard's column 80; this fixes it for the lint gate.
Changes
Add a ruff.toml at the repo root selecting the rule set explicitly:
[lint]
select = ["E4", "E7", "E9", "F"]
with a comment recording why the selection is explicit rather than inherited. The hook and CI stay unpinned — the config, not the version, is what fixes the meaning, and a newer ruff is then free to bring bug fixes without silently changing the bar.
Acceptance criteria
Out of scope
Whether the repo should adopt the wider ruleset. The 31 findings are mostly real (23 are a missing explicit check= on subprocess.run) and several are worth fixing on their merits. That is a decision to take deliberately, on its own ticket — not one to have forced by an upgrade.
Why
.pre-commit-config.yamland CI both run ruff unpinned:and the repo carries no ruff configuration, so the rule set is whatever that day's ruff calls its default. That default is not a stable contract. Ruff 0.16.4 widened it from roughly 60 rules to 413, and a tree that had been green went red on 31 findings in code nobody had touched:
PLW1510subprocess-run-without-checkTRY004type-check-without-type-errorEXE001shebang-not-executableSIM102collapsible-ifDTZ011call-date-todayBecause
ruff-checkis the first pre-commit hook, this blocked every commit in the repository, including one whose own five checks were otherwise green. Under ruff's historical default set (E4,E7,E9,F) the tree passes cleanly, so nothing in the code regressed — only the question being asked of it changed.Found while committing #59, which is the same failure one level up: a rule whose meaning depends on the reader's environment rather than being written down. #59 fixed it for the coding standard's column 80; this fixes it for the lint gate.
Changes
Add a
ruff.tomlat the repo root selecting the rule set explicitly:with a comment recording why the selection is explicit rather than inherited. The hook and CI stay unpinned — the config, not the version, is what fixes the meaning, and a newer ruff is then free to bring bug fixes without silently changing the bar.
Acceptance criteria
uvx ruff check .passes on a clean treeruff.toml, not a surprise on upgrade dayOut of scope
Whether the repo should adopt the wider ruleset. The 31 findings are mostly real (23 are a missing explicit
check=onsubprocess.run) and several are worth fixing on their merits. That is a decision to take deliberately, on its own ticket — not one to have forced by an upgrade.