feat(tools): add a module filter and JSON output to progress.py

[Gabrieljr42]

What

tools/progress.py accepts a repeatable --module NAME that limits library totals to those directories under core/libs/prx, and --json that prints the progress.json object to stdout. Shader counts stay complete. A shared-source wrapper is included only when its own directory is named. The output directory is optional when either flag is set. A run that only names the directory still writes the whole tree.

The five generated site files are explicitly written as UTF-8, including Unicode module names on Windows.

Tested

Windows, CPython 3.12.14 with native CP1252 encoding verified. The new real-CLI regression reproduces the UnicodeEncodeError before the fix with -X utf8=0, PYTHONUTF8=0 and PYTHONIOENCODING=cp1252. After the fix, all five site files decode as UTF-8, the Unicode module name is preserved, and the JSON totals remain 1/1.

All 40 progress-related tests pass:

python -m unittest tools.tests.test_progress tools.tests.test_progress_history tools.tests.test_progress_encoding tools.tests.test_progress_read_encoding tools.tests.test_progress_render_sliver tools.tests.test_progress_wrappers

python tools/check_conventions.py --base origin/main also passes. Rebased onto 44df21632 from main. No native build, hardware/title, Linux or macOS testing.

Checklist

• Based on current main; no other open PR implements the same functions
• One topic per PR; follow-ups go in a new PR
• No comments in code except technical debt
• Unimplemented paths throw (NotImplemented_nid_no_patch); silent stubs are listed under Silent stubs in their library's technical debt file
• No notes, investigation .md files or images added to the repository (attach them to this PR)
• New third-party code is a submodule built from source
• Generic behaviour, not specific to one title
• Depends on: none
• Unblocks: none
• GPUs tested: n/a
• AI-assisted: yes

[simonbronk]

Windows encoding follow-up for write_site at head ef88d3d (AI-assisted).

The entry point sets stdout to UTF-8, but the five Path.write_text calls still use the platform file encoding. With Windows CP1252 and UTF-8 mode disabled, a Unicode-named module selected with --module is scanned correctly, then generation crashes in progress.svg with UnicodeEncodeError, after earlier site files have already been written.

The attached patch adds encoding="utf-8" to the five write_site writes. Counting, filtering, stdout and newline policy are unchanged. A new regression runs the real CLI subprocess with -X utf8=0, PYTHONUTF8=0 and PYTHONIOENCODING=cp1252 against a synthetic root containing one implemented function in a Unicode-named library. It checks that all five files decode as UTF-8, SVG/HTML retain the label and JSON retains the name and 1/1 totals.

Windows 11, CPython 3.12.14 (native CP1252 default verified):

• Regression-only baseline: 40 selected progress tests, one failure, zero errors (4.657 s).
• Fixed tool: all 40 pass, zero skips (4.559 s).
• git apply --check passes against the recorded original files.

The suites cover progress, encoding, history, read_encoding, render_sliver and wrappers. I checked #6447's progress.py edit: it changes label clipping, not file encodings.

Bundle: applicable patch, regression, exact original/fixed tool/test dependencies and results. Isolated Python/synthetic validation only; no full-tools/conventions suite, current-main composition, CTest/native build, GPU/title/FPS or Linux/macOS testing. No changes pushed to your branch.

progress-site-utf8-pr6323.zip

[Gabrieljr42]

Thanks for catching this, @simonbronk. Fixed in 3a2e9d2: all five site files now use explicit UTF-8. The new CLI regression reproduces the CP1252 failure before the fix and passes afterward. All 40 progress-related tests and the conventions check pass on Windows. I also rebased onto 44df216 from main and checked #6447; its label-clipping change doesn't overlap this fix.

[simonbronk]

Verified 3a2e9d2 on Windows 11, CPython 3.13.15 with the native CP1252 default: the six progress suites run 40 tests, all pass (4.56 s). With tools/progress.py from the earlier head ef88d3d and the new regression, test_progress_encoding fails once, as expected. Thanks for the quick fix.

[github-actions]

Some comparisons could not be completed because a pull request conflicts with the base branch. Review these shared files manually before concluding that there is no overlap.

Pull request	Shared files not compared
PR 6039	docs/dev/PROGRESS.md

[Gabrieljr42]

I manually checked the shared docs/dev/PROGRESS.md changes against #6039 at bda261497.

#6039 changes the opening paragraph's workflow link from Progress to Pages. This PR adds the --module / --json documentation and examples farther down, so the documentation edits don't overlap.

#6039 currently conflicts with its base branch, which prevents the bot from completing that comparison. GitHub reports no merge conflict for this PR at 3a2e9d294.