Add tool to keep test-requirements in sync with pre-commit

[CoolCat467]

In this pull request, we add a local pre-commit hook tool to keep the tool versions in test-requirements.txt in sync with the equivalent versions in .pre-commit-config.yaml automatically, meaning pre-commit.ci automatic updates are more seamless and there can never be cases where the test versions don't match the pre-commit versions.

[codecov]

Codecov Report

Attention: Patch coverage is 85.36585% with 12 lines in your changes missing coverage. Please review.

Project coverage is 99.93727%. Comparing base (d65d3f6) to head (200b221).

Files with missing lines	Patch %	Lines
src/trio/_tools/sync_requirements.py	78.57143%	10 Missing and 2 partials ⚠️

Additional details and impacted files

@@                 Coverage Diff                  @@
##                 main       #3234         +/-   ##
====================================================
- Coverage   100.00000%   99.93727%   -0.06274%     
====================================================
  Files             124         126          +2     
  Lines           19047       19129         +82     
  Branches         1287        1296          +9     
====================================================
+ Hits            19047       19117         +70     
- Misses              0          10         +10     
- Partials            0           2          +2     

Files with missing lines	Coverage Δ
src/trio/_tests/tools/test_sync_requirements.py	100.00000% <100.00000%> (ø)
src/trio/_tools/sync_requirements.py	78.57143% <78.57143%> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[A5rocks]

Thanks this makes sense and seems pretty simple. We could probably make it simpler too.

I wonder whether maybe this should update the pre-commit configuration too, to maximize the version (lexicographically? Or just import packaging) between both files.

Another helpful related script might be to copy the pins from the requirements.txt files to the pre-commit file.

[A5rocks]

I kind of feel like a loop over the version_data dict with a regex replacement might be simpler. Though this is already plenty simple.

[A5rocks]

IMO we should just do a dict of url to package name at the top instead of trying to automatically detect it

[CoolCat467]

I was intending for this to be general enough to work even if new hooks are added in the future, but if necessary I could change it to be a static dictionary

[A5rocks]

This should also check whether every entry in version_data was used

[CoolCat467]

I don't immediately understand why this should be the case. For example, typos exists only as a pre-commit hook, and in fact I don't know if it even exists as a python package. Similar with zizmor.

[A5rocks]

Yeah this would only make sense if #3234 (comment) was implemented.

[CoolCat467]

I wonder whether maybe this should update the pre-commit configuration too, to maximize the version (lexicographically? Or just import packaging) between both files.

Another helpful related script might be to copy the pins from the requirements.txt files to the pre-commit file.

While this could be useful in some cases, I don't see a need for that in a regular use case. From my point of view, most of the time someone (or pre-commit.ci) would run pre-commit autoupdate and then uv pip compile --universal --python-version=3.9 test-requirements.in -o test-requirements.txt --upgrade, and then since all the pre-commit hook versions are either the original package itself or a mirror, they should have an identical version.

The primary use case for this script is so that when pre-commit ci automatically updates everything, this will automate pinning the test requirements to the same version.

Another possible solution that would sidestep needing this tool in the first place would be to just have pre-commit ci perform an upgrade on all the test requirements as well, but I don't think there is a way to specify a pre-commit hook to run that only runs on pre-commit.ci but not locally, unless one were to write a script to somehow identify something in the pre-commit.ci environment that is different from a local run.