Repository navigation
Read the CI Python versions from the recipes' conda_build_config.yaml - #264
Conversation
List the Python versions as full specs in the python: key of conda-recipe/conda_build_config.yaml and conda-recipe-cf/conda_build_config.yaml, the way conda-forge pinning lists them, instead of in the matrix of conda-build-test.yml and the python-versions input. A new variants job in conda-build-test.yml outputs the build/test matrix from that list with a new composite action, .github/actions/conda-python-matrix. Its script reads the list without rendering the recipe, using only the standard library, and rejects bare versions and selectors, so every job gets an explicit ABI, as the 3.14 and 3.15 rows had before. The build job passes each entry to conda build --python, which selects that single variant from the list. The action refers to nothing outside its directory, so it can move to a shared repository together with conda-build-test.yml. The build and test jobs get explicit names, so the check names stay those of the former static matrix: "Build (3.12)" for a version with one build, "Build (3.14, 3.14.* *_cp314t, 3.14t)" for a version with GIL and free-threaded builds. The master ruleset requires the 3.14 Test checks by these names. Update the AGENTS.md files: the Python versions now come from the recipes, a plain "conda build <recipe>" builds all of them, and the action's uses: line must switch to the $/ self-repository syntax when it moves, which actionlint does not support yet.
005b567 to
4f6d0db
Compare
|
Side effect check: with the FYI, harmless: the build-string hash is now per Python version ( |
A comment at column 0 inside the python: list ended the list, so the entries after it were dropped from the matrix without an error, while conda-build, which reads the file as YAML, still saw them. Skip comment lines instead. Reject an entry whose ABI doesn't match its version (3.13.* *_cp314t was accepted and tagged 3.13t), and a second entry for a build already listed, such as a duplicate line or 3.12.* *_cpython next to 3.12.* *_cp312: both failed only later, when the artifact names collided. Since the build job runs conda build from the base environment, no job reads the python field of the matrix any more, so drop it.
The python: lists in the recipes' conda_build_config.yaml are now the only place the conda workflows take their Python versions from; listing them again in AGENTS.md brings back the drift that moving them there removed. Say where they come from instead. Document the new checks of the variants job, and drop the policy line about repeating experimental in include rows: no workflow uses experimental any more.
No, I checked the internal pipeline's logs. Every conda build job (dev and prod, Linux and Windows, 3.10 to 3.14t, packages and wheels) passes On the hash: agreed, it's harmless. The internal builds keep their hashes, because they pass either a bare version or the same spec as before. |
vlad-perevezentsev
left a comment
vlad-perevezentsev
left a comment
There was a problem hiding this comment.
No more comments from my side
LGTM
Thank you @antonwolfy
conda-forge no longer builds Python 3.10. The list now has the same entries as the one #264 adds, so whichever of the two lands second keeps one of them.
Summary
The Python versions that the conda workflows build and test now come from the
python:list in each recipe'sconda_build_config.yaml, in the spec format conda-forge pinning uses:This replaces the static matrix in
conda-build-test.yml, the hard-coded 3.14/3.15 rows, and thepython-versionsinput 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
variantsjob runs a new composite action,.github/actions/conda-python-matrix, which reads thepython: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.14has been observed to pick the free-threaded build. It also fails on an ABI that doesn't match the version (3.13.* *_cp314t) and on a second entry for the same build, whose artifact names would collide. Quoted entries are accepted, and comment lines are skipped. You can run it locally:python .github/actions/conda-python-matrix/conda_python_matrix.py conda-recipe-cf/conda_build_config.yaml.conda build --python "<spec>". With the full list in the config, conda-build then builds only that one variant: renderingconda-recipe-cfgives 7 variants without--pythonand exactly one (python 3.14.10 *_cp314t) with--python "3.14.* *_cp314t".Build (3.12)for a version with one build andBuild (3.14, 3.14.* *_cp314t, 3.14t)for a version with GIL and free-threaded builds. The master ruleset requires the six 3.14Testchecks 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 asTest (${{ matrix.label }})instead ofTest.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
_cpythonbuild strings, so3.12.* *_cpythonstill resolves to the Intel channel'spython 3.12.8(he267403_8_cpythonon linux-64,h3c23a9a_8_cpythonon win-64), as the bare3.12did. 3.13 and 3.15 come from conda-forge (*_cp313,*_cp315t), as before.Side effect: a plain
conda build conda-recipe(orconda-recipe-cf) now builds every listed Python version. Pass--python "3.12.* *_cpython"to build one;conda-recipe/AGENTS.mdsays 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, theuses:line in thevariantsjob 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.mdrecords this.Changes
conda-recipe/conda_build_config.yaml,conda-recipe-cf/conda_build_config.yaml: add thepython:lists.github/actions/conda-python-matrix/: new composite action (action.yml,conda_python_matrix.py)conda-build-test.yml: newvariantsjob; build and test use its matrix and explicit names; thepython-versionsinput and the static matrices are removedconda-package-cf.yml: stop passingpython-versionsAGENTS.mdfiles: the policy "keep the Python matrix in workflow files" becomes "the conda workflows read it from the recipe" (build_pip.ymland the clang workflows keep their own matrices); document the spec rules, the check-name constraint, and the actionTest plan
pre-commit(including black, flake8, isort, pylint and actionlint) andzizmor --min-severity medium .github/report no findingspython:key, an ABI that doesn't match the version, and a second entry for the same build; it accepts quoted entries and skips comment lines, also at column 0 inside the listconda renderwith the in-recipe list selects a single variant per--pythonspec, forconda-recipe-cf(conda-forge) andconda-recipe(Intel channel; linux-64 and win-64 for 3.12, 3.13 and 3.15t)BuildandTestcheck names as Build the conda-forge workflow like the conda-forge feedstock #263, plus oneVariantsjob per platform