Windows ARM64 jobs may need x64 Python independently of their Python
version pin. Add `python-arch` to export `UV_PYTHON_ARCH` for subsequent
steps and include the selected architecture in the uv and managed-Python
cache keys. The input takes precedence over an inherited environment
value, and unsupported uv versions fail before environment creation.
Requires a uv release with `UV_PYTHON_ARCH` support.
https://github.com/pyca/cryptography/pull/15572#discussion_r3913508686
has the context for this: TL;DR our current `python-version` output
mirrors the "request" version exactly, which means that it's
insufficient for any downstream that needs to manage its own cache keys
(since caches shouldn't be shared across release candidates, but the `uv
python` request version doesn't include RC numbers).
The first commit here was my attempt to fix this by exposing the runtime
Python version, but this too is imprecise: the runtime version doesn't
indicate the interpreter variant (e.g. freethreading), which is also
important to capture in the cache identity.
My solution here is to expose `python-runtime-id`, which is just the
`key` of the active Python version from `uv python list
--output-format=json`.
---------
Signed-off-by: William Woodruff <william@yossarian.net>
## Summary
- update README and docs `uses: astral-sh/setup-uv@...` examples to the
v8.2.0 commit SHA
- replace stale `v8.1.0` comments with `v8.2.0`
Fixes#931
## Validation
- npm ci --ignore-scripts
- npm run all
Update all README and docs examples to use the pinned v8 release SHA for
astral-sh/setup-uv, with a comment showing the release version for
clarity and best practices.
Zanie Blue