[antonwolfy]

Stacked on #262; the diff shows only this PR's changes. GitHub retargets it to master once #262 is merged.

Summary

conda-package-cf.yml is meant to catch problems before they reach conda-forge/mkl-service-feedstock, but it built and tested conda-recipe-cf/ differently from the feedstock. I compared it with the feedstock at main (2.9.0 build 2, re-rendered 2026-10-12) and with the logs of today's master run 40669276773:

	Feedstock	conda-package-cf.yml before	After this PR
Linux gcc	15	16.2 (no pin), so the package required libgcc >=16	15 (libgcc >=15)
macOS clang	21	23.1 (no pin)	21
mkl_devel	2026	no pin	2026 (not on macOS, where the recipe has mkl-devel <2024)
Tests	recipe test: section (pip check, import, pytest)	--no-test; the test job ran its own pytest only	recipe test: section, through conda build --test in the test job
Python	3.11-3.15, 3.14t	3.10-3.15, 3.14t, 3.15t	3.11-3.15, 3.14t, 3.15t
Windows image	windows-2022	windows-latest (Visual Studio 2026)	windows-2022
pip install in build scripts	-v	no -v, so the meson output was hidden	-v

Already the same before this PR: the recipe's requirements and test section, sysroot 2.17, macOS deployment target 11.0, and the run dependencies on mkl. On windows-latest the vs2022 activation already loaded the 14.44 toolset from the Visual Studio 2026 install, but the job depended on that image keeping the older toolset.

3.15t stays in the matrix even though the feedstock has no 3.15t build yet: conda-forge has not started that migration, and the job is an early warning for it. The macOS SDK still differs (the runner's Xcode 26.6 SDK here, MacOSX 11.0 in the feedstock). Matching it would mean downloading the SDK the way conda-forge's CI does, and with the same deployment target it doesn't seem worth it.

Test job: conda build --test

In both workflows the test job now runs conda build --test on the downloaded package instead of indexing a local channel, reading the version from conda search, installing the package and running pytest. CI then runs the test section of the recipe, as the feedstock does:

• conda-recipe-cf: pip check, import mkl, pytest -vv --pyargs mkl
• conda-recipe: import mkl, pytest -vv --pyargs mkl

The build job keeps --no-test, so the tests run once, on a fresh runner rather than on the machine that just built the package. The test environment's Python comes from the package's python_abi dependency, so the free-threaded packages still get a free-threaded interpreter without python_spec. Test-only dependencies now belong in the recipes' test: requires:, which the mkl/tests/AGENTS.md notes now say.

I tried this locally on two packages built by #262's CI: the 3.12 package got python 3.12.16 *_cpython and passed pip check, the import test and pytest (188 passed, 22 skipped), and the 3.14t package got python 3.14.10 *_cp314t (191 passed, 19 skipped). Passing --override-channels works, because conda-build copies the package into its own local channel.

Changes

• conda-recipe-cf/conda_build_config.yaml: pin c_compiler_version (gcc 15 on Linux, clang 21 on macOS) and mkl_devel 2026, as conda-forge pinning does
• conda-recipe-cf/build.sh, bld.bat: pip install -v, as in the feedstock
• conda-build-test.yml:
  • new python-versions input, a JSON list of the versions besides 3.14/3.15 (default ["3.10", "3.11", "3.12", "3.13"], which keeps conda-package.yml unchanged)
  • test job: conda build --test replaces seven steps, and the env vars and version-parsing script that only those steps used are gone; the test matrix keeps python_spec, so check names don't change
  • matrix values used in run: steps move to env:, because zizmor flags them once the matrix depends on an input
• conda-package-cf.yml: python-versions: '["3.11", "3.12", "3.13"]' and windows-2022 for the Windows jobs
• AGENTS.md files: document the conda-forge workflow's Python versions and pins, the rule to update them when the feedstock is re-rendered, how the test jobs run the recipe tests, and that macOS is built from conda-recipe-cf/ (the old note said macOS wasn't built)

Test plan

• pre-commit (including actionlint and shellcheck) passes on the changed files
• zizmor --min-severity medium .github/ reports no findings
• conda render conda-recipe-cf for linux-64, win-64 and osx-64 resolves gcc 15.3 with libgcc >=15, clang 21, vs2022, and mkl-devel 2026.1.0 (2023.2.0 on macOS); overriding mkl_devel to 2025 switches to mkl-devel 2025.3.1, so the variant key takes effect
• conda build --test run locally on Drop the conda package cache from the conda CI workflows #262's linux-64 3.12 and 3.14t conda-forge packages passes, with the right Python ABI
• Conda package using conda-forge is green on this PR, with no 3.10 jobs
• Conda package using Intel is green on this PR