Skip to content

style: reformat classify_documents.py to satisfy CI-pinned ruff 0.13.1#137

Merged
FlowElement-ai merged 1 commit intomainfrom
fix/ruff-format-drift-classify-documents
May 1, 2026
Merged

style: reformat classify_documents.py to satisfy CI-pinned ruff 0.13.1#137
FlowElement-ai merged 1 commit intomainfrom
fix/ruff-format-drift-classify-documents

Conversation

@FlowElement-ai
Copy link
Copy Markdown
Owner

Summary

Unblocks the Fork PR lightweight checks CI gate that has been silently failing on every recent fork PR (e.g. #131, #134, #135).

Root cause

uv.lock pins ruff 0.13.1, and .github/workflows/test_suites.yml::fork-lite runs uv run ruff format --check . over the whole tree. After PR #131's dict.fromkeys autofix landed (using a newer ruff locally), the 16-element _IMAGE_EXTS list ended up on a single line that exceeds the project's 120-char limit. ruff 0.13.1 wants that list re-expanded.

Because the format drift is on a file that no fork PR is touching, every subsequent fork PR fails the same ruff format --check step on a file unrelated to its changes.

Fix

Run ruff==0.13.1 format on the file. After this PR the entire tree reports 1061 files already formatted under the locked ruff version.

Test plan

  • uv run --no-project --with "ruff==0.13.1" ruff format --check . → all files clean
  • uv run --no-project --with "ruff==0.13.1" ruff check . → all checks passed
  • No functional change — only whitespace within an existing list literal

I affirm that all code in every commit of this pull request conforms to the terms of the M-flow Developer Certificate of Origin.

Made with Cursor

The repo's `uv.lock` pins `ruff==0.13.1` and the fork-lite CI job runs
`uv run ruff format --check .` against the whole tree. After PR #131
(``dict.fromkeys`` autofix) was merged via a different ruff version, the
16-element ``_IMAGE_EXTS`` list ended up on a single line that exceeds
the project's 120-char limit. ruff 0.13.1 wants the list re-expanded;
the resulting drift was silently breaking every subsequent fork PR's
``Fork PR lightweight checks`` step (observed on PRs #131, #134, #135).

Re-run ``ruff==0.13.1 format`` on the file. Tree is now ``1061 files
already formatted`` under the locked ruff version.
@FlowElement-ai FlowElement-ai merged commit e605331 into main May 1, 2026
100 checks passed
@FlowElement-ai FlowElement-ai deleted the fix/ruff-format-drift-classify-documents branch May 1, 2026 17:55
FlowElement-ai added a commit that referenced this pull request May 1, 2026
…t upper bound (#142)

`pyproject.toml` declared `ruff>=0.9.0,<=0.15.10` but `uv.lock` was still
pinned at 0.13.1, releases behind. Contributors who installed ruff
manually (or whose editor picked up a newer ruff) ran format autofixes
that 0.13.1 would refuse, producing CI noise on every fork PR even when
the code was logically correct.

This was the direct root cause of:

- PR #137 (the one-off `classify_documents.py` reformat I had to land)
- The persistent `Fork PR lightweight checks` failures on PR #131,
  #134, and #135 — all caused by `ruff==0.13.1` reformatting files the
  contributors' newer ruff considered correct
- Several earlier rounds of "fork-lite is red even though the diff
  looks fine" debugging

`uv lock --upgrade-package ruff` snaps the lock file to the constraint
ceiling (0.15.10). Verification on main:

- `ruff==0.15.10 format --check .` → 1061 files already formatted
- `ruff==0.15.10 check .` → all checks passed

So the upgrade introduces zero source code change and aligns the CI
ruff with what contributors and their editors are running.

Co-authored-by: Junting Hua <juntinghua@Juntings-MacBook-Pro.local>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant