Regenerate requirements.txt from uv.lock

[dillonbbailey]

Summary

requirements.txt was last refreshed for v1.5.1 (December 2025), while uv.lock has since moved to v1.6.2. Nothing in the repo reads requirements.txt — both CI jobs install with uv sync — so the drift went unnoticed. Dependency scanners still treat it as a manifest, though, and report vulnerabilities against versions the project no longer installs.

Most notably it advertised usd-core==25.5, which carries GHSA-58p5-r2f6-g2cj, a critical Sdf_PathNode use-after-free. The lockfile resolved that when it moved to 25.11.

Changes

Regenerated from uv.lock, bringing four packages back in line and adding pytest, which became a project dependency after the last refresh:

Package	Before	After
usd-core	25.5	25.11
urllib3	2.5.0	2.6.3
requests	2.32.4	2.32.5
marshmallow	3.26.1	3.26.2

Plus pytest==9.0.2, pluggy==1.6.0, iniconfig==2.3.0. Nothing removed.

The uv export command is now recorded in a header comment so the file can be regenerated reproducibly instead of drifting again.

Verification

• Querying OSV against the file before and after: 26 → 22 advisories, and no remaining critical.
• Two entries appear that were not there before, both expected rather than regressions: a pytest advisory that was previously invisible because pytest was missing from the file entirely, and a urllib3 advisory specific to the 2.6.x line — urllib3 still nets 4 → 2 overall.
• The documented uv export command reproduces the file byte-for-byte.
• Every line parses as a valid requirement.

No Sphinx build or test run was performed: requirements.txt is referenced nowhere outside a descriptive line in AGENTS.md, and CI installs from the lockfile, so this file cannot affect the build.

Worth discussing

This fixes the symptom. The file drifted because nothing consumes it and there was no documented way to regenerate it — the header comment helps, but it will drift again by the next release unless the export is wired into the release process. Given uv.lock is the real source of truth, removing requirements.txt altogether may be the better long-term answer. Happy to follow up either way.

🤖 Generated with Claude Code