[antonwolfy]

Stacked on #263 (itself on #262); the diff shows only this PR's change. GitHub retargets it as the PRs below it are merged.

Summary

The Python versions that the conda workflows build and test now come from the python: list in each recipe's conda_build_config.yaml, in the spec format conda-forge pinning uses:

python:
    - 3.11.* *_cpython
    - 3.12.* *_cpython
    - 3.13.* *_cp313
    - 3.14.* *_cp314
    - 3.14.* *_cp314t
    - 3.15.* *_cp315
    - 3.15.* *_cp315t

This replaces the static matrix in conda-build-test.yml, the hard-coded 3.14/3.15 rows, and the python-versions input added in #263. conda-recipe/ lists 3.10-3.15 with 3.14t and 3.15t; conda-recipe-cf/ lists the feedstock's versions (3.11-3.15, 3.14t) plus 3.15t. To change the set, you now edit the recipe.

How it works

• A new variants job runs a new composite action, .github/actions/conda-python-matrix, which reads the python: list from the caller's recipe and outputs the matrix for the build and test jobs. Its script, conda_python_matrix.py, uses only the standard library and doesn't install conda or render the recipe. It fails on bare versions (3.12) and on selectors, so every job gets an explicit ABI; that matters because a bare --python 3.14 has been observed to pick the free-threaded build. Quoted entries are accepted. You can run it locally: python .github/actions/conda-python-matrix/conda_python_matrix.py conda-recipe-cf/conda_build_config.yaml.
• The build job passes each entry to conda build --python "<spec>". With the full list in the config, conda-build then builds only that one variant: rendering conda-recipe-cf gives 7 variants without --python and exactly one (python 3.14.10 *_cp314t) with --python "3.14.* *_cp314t".
• The build and test jobs get explicit names built from the matrix, so the check names don't change: Build (3.12) for a version with one build and Build (3.14, 3.14.* *_cp314t, 3.14t) for a version with GIL and free-threaded builds. The master ruleset requires the six 3.14 Test checks by these exact names. I compared the generated names with the 46 conda checks reported on Build the conda-forge workflow like the conda-forge feedstock #263, and they are identical. One cosmetic difference: when a failed build skips the whole Test job, GitHub never expands its matrix, so that check shows as Test (${{ matrix.label }}) instead of Test.
• Artifact names are unchanged. They use python_tag, which is now always set (3.12, 3.14, 3.14t, ...).

The exact specs keep the Intel workflow's Python builds the same: Intel-channel Python packages also have _cpython build strings, so 3.12.* *_cpython still resolves to the Intel channel's python 3.12.8 (he267403_8_cpython on linux-64, h3c23a9a_8_cpython on win-64), as the bare 3.12 did. 3.13 and 3.15 come from conda-forge (*_cp313, *_cp315t), as before.

Side effect: a plain conda build conda-recipe (or conda-recipe-cf) now builds every listed Python version. Pass --python "3.12.* *_cpython" to build one; conda-recipe/AGENTS.md says so.

Prepared for the shared workflow

The action's directory refers to nothing outside itself, so it can move to a shared repository together with conda-build-test.yml. After that move, the uses: line in the variants job must change from ./.github/actions/conda-python-matrix (which resolves against the caller's checkout) to $/.github/actions/conda-python-matrix. GitHub's self-repository syntax resolves against the repository of the workflow file itself and needs no checkout. It isn't $/ already because actionlint 1.7.12, used by pre-commit, rejects that syntax (rhysd/actionlint#711). .github/AGENTS.md records this.

Changes

• conda-recipe/conda_build_config.yaml, conda-recipe-cf/conda_build_config.yaml: add the python: lists
• .github/actions/conda-python-matrix/: new composite action (action.yml, conda_python_matrix.py)
• conda-build-test.yml: new variants job; build and test use its matrix and explicit names; the python-versions input and the static matrices are removed
• conda-package-cf.yml: stop passing python-versions
• AGENTS.md files: the policy "keep the Python matrix in workflow files" becomes "the conda workflows read it from the recipe" (build_pip.yml and the clang workflows keep their own matrices); document the spec rules, the check-name constraint, and the action

Test plan

• pre-commit (including black, flake8, isort, pylint and actionlint) and zizmor --min-severity medium .github/ report no findings
• The script, run on both configs, produces the expected entries; their names match all 46 conda check names on Build the conda-forge workflow like the conda-forge feedstock #263
• The script rejects a selector on an entry or on the key, a bare version, a missing list, and a duplicate python: key, and accepts quoted entries
• conda render with the in-recipe list selects a single variant per --python spec, for conda-recipe-cf (conda-forge) and conda-recipe (Intel channel; linux-64 and win-64 for 3.12, 3.13 and 3.15t)
• On the previous revision of this PR, the Intel workflow was green with the same check names as Build the conda-forge workflow like the conda-forge feedstock #263
• CI on this revision has the same jobs and check names as Build the conda-forge workflow like the conda-forge feedstock #263. The conda-forge Windows test jobs are expected to keep failing until conda-forge ships a pytest with its colorama dependency restored, as on Build the conda-forge workflow like the conda-forge feedstock #263