feat: add dynamically generated sysconfig replacement mappings

[samypr100]

Summary

Implementation referenced in https://github.com/astral-sh/uv/pull/12239#issuecomment-2744880003

Closes #12919 #12901

This makes the sysconfig replacements mappings dynamically generated from https://github.com/astral-sh/python-build-standalone/blob/main/cpython-unix/targets.yml

Test Plan

Still in progress... draft for now.

[samypr100]

@zanieb Are you ok with this general approach? There is an big assumption here that targets.yml will be the canonical way to obtain these mappings going forward.

It has the (good? or bad?) side-effect that as soon as targets.yml adds a new non-mapped entry, it will fail the generate tests. We can lock it down to only reference build-standalone releases though, but that may require manual updating/upkeep.

[zanieb]

Are you ok with this general approach?

I think so? The targets file may change, but I do think static declaration of the targets is helpful.

I can take a closer look, but I'm at the PyCon Sprints this week and am pretty distracted.

@Gankra might have some thoughts.

[samypr100]

This all seems vaguely coherent and yeah using a source of truth seems good. Could you give some insight on why the shell script if the rust code already needs to know how to do http requests to github?

Good question. The shell script exists to update the python-build-standalone release tag used by the .rs file for to generate the sysconfig metadata. This was a change done after https://github.com/astral-sh/uv/pull/13441#discussion_r2096703347.

Alternatively, could the work the script does be done by fetch-download-metadata.py, so local invokers can just run One Thing?

My thought was to integrate it with the existing cargo dev workflow and tests. I think an alternate script would suffer from the same situation? We'd have to be specific about the release tag we would be pulling in the changes from and it would have to be routinely updated as per https://github.com/astral-sh/uv/pull/13441#discussion_r2096703347 it was not desirable to point it main. Some other options I can think about are

1. Make a change to the existing code to point to the latest release tag instead every time (rather than main) which will make it "break" less often when running the cargo dev tests (or equivalent alternate python script run).
2. We use an environment variable on the existing .rs file instead to control the tag it pulls from and leave it unset locally (making the tests pass when its unset), but CI sets it.

[codspeed-hq[bot]]

CodSpeed Walltime Performance Report

Merging #13441 will improve performances by 15.79%

_{Comparing samypr100:dynamic-sysconfig (c92019a) with main (13a86a2)}

Summary

⚡ 1 improvements
✅ 11 untouched benchmarks

Benchmarks breakdown

	Benchmark	BASE	HEAD	Change
⚡	wheelname_parsing_failure[flyte-long-extension]	110 ns	95 ns	+15.79%