ci(health): bump pyscn to 1.32.4 and read its snake_case report

[thodson-usgs]

Closes #415. The pyscn author raised two points in that issue: we analyzed the package twice to get both report formats, and our sanity check would read pyscn's JSON with the old key names after an upgrade.

Change

• Pin: pyscn==1.32.4, up from 1.29.0, in the [health] extra.

• One run: pyscn analyze --json --html --no-open dataretrieval writes both reports, replacing the two separate runs.

• Sanity step:

  • It reads the snake_case keys that pyscn 1.30.0 introduced (system.summary.project_root, total_dependencies, total_modules).
  • A missing key is named in the summary rather than raising to stderr, so a future rename shows up instead of dropping the line.
  • It warns separately when the root is not the checkout and when pyscn analyzed fewer than 90% of the package's .py files.
  • It does not use pyscn's new unresolved_imports count. Under a wrong root, pyscn counts the package's own imports as external, so the count stays 0. A copy of the package analyzed under another root gave 15 modules, 5 dependencies and 0 unresolved imports.

• .pyscn-known-clones.json is regenerated with 1.32.4. Two defaults changed in pyscn: clone grouping went from connected to complete_linkage, and min_lines from 10 to 8. As a result, 1.32.4 no longer reports the NGWMN, NWIS and WQP getter families as clone groups. It reports two new small pairs instead, the _validation checks reject_together/require_any_of and NWDC's _validate_county/_validate_huc, each recorded with a rationale.

  The file was already out of date: 1.29.0 reports 10 groups on today's main, while the file recorded 5.

  The file also changes in these ways:

  • default_thresholds records group_mode, group_threshold, skip_docstrings and clone_types.
  • The 2026-08-09 docstring measurements are marked as 1.29.0 only, because 1.32.4 skips docstrings.
  • The Water Data rationales no longer cite docstrings.
  • The marginal type-4 pair (similarity 0.672) has its own rationale.

• Docs: pyproject.toml and CONTRIBUTING.md now list the new Linux ARM64 wheel and say the 1.32.4 Linux wheels need glibc 2.34 or later (1.29.0's needed 2.17). There is no sdist, so .[health] no longer installs on RHEL 8, Ubuntu 20.04, Debian 11 or Amazon Linux 2. CONTRIBUTING also mentions --json --html.

Comparison on main (macOS ARM64)

	1.29.0	1.32.4
Health score	77	87
Duplication	65 (10 groups)	95 (5 groups)
Coupling	85	95
Architecture	84	91
Dependencies	70 (depth 11)	70 (depth 13)
Project root	checkout	checkout
Unresolved imports	not reported	0

Both versions resolve the checkout as the root. The score rise comes from the new version's scoring, not from any code change, so the next weekly run is a new baseline.

I ran the updated workflow by hand on this branch from my fork (run). Every step succeeded, the sanity step printed modules=62 files=62 dependencies=198 root=/home/runner/work/dataretrieval-python/dataretrieval-python with no warning, and the artifact contains both the JSON and the HTML report. Locally, the check printed both warnings for a report edited to a wrong root and 15 modules, and named the key for a report with project_root removed. Pre-commit passes.

For the issue author

The project-root comment was written defensively when the workflow was added. In the weekly runs I checked (08-24, 09-07 and 10-12), the reported root was always the checkout and the warning never fired, so I have no run where it went wrong.

Follow-ups, not in this PR

• No step compares the report's clone groups with .pyscn-known-clones.json, which is how the file drifted.
• The NWDC _validate_county/_validate_huc pair is private, so the file's reason for accepting clones does not apply. One helper could replace both, and their messages lack a remedy.

🤖 Generated with Claude Code

https://claude.ai/code/session_01HBt3Ee7eneKtdKQWq2T3YK