Migrate conda packaging to rattler-build (v1 recipe format) for GitHub Actions CI

[ekomarova]

Add rattler-build support for GitHub Actions CI

Summary

This PR adds rattler-build as the package-building tool for the Conda package GitHub Actions workflow, alongside a new rattler_recipe.yaml (v1 recipe schema) generated from the existing meta.yaml.

meta.yaml is left untouched and fully functional. This PR only changes what runs on GitHub Actions; it does not retire or replace the conda-build path.

What changed

• .github/workflows/conda-package.yml: build steps now call rattler-build instead of conda-build

• conda-recipe/rattler_recipe.yaml: new file, the rattler-build (v1 schema) equivalent of meta.yaml. A handful of things had to be restructured because v1 format must always be valid plain YAML (no Jinja control-flow blocks)

• environments/build_conda_pkg.yml: no longer needed for use

• conda-recipe/bld.bat: unchanged, still the source file for conda-build; a CI step copies it to build.bat on Windows runners since that's the filename rattler-build expects

Why these specific changes were needed

• CONDA_BLD path — rattler-build outputs to output/<platform>/ relative to the working directory by default, unlike conda-build's $CONDA_PREFIX/conda-bld/

• Compute version from git describe step — conda-build runs git describe internally before rendering to populate GIT_DESCRIBE_TAG/GIT_DESCRIBE_NUMBER. rattler-build has no equivalent, so rattler_recipe.yaml now reads these via env.get(...), and we compute + export them ourselves beforehand.

• Prepare build.bat for rattler-build step — rattler-build expects build.bat (symmetric with build.sh), while conda-build (still used in non-GitHub CI) only recognizes bld.bat. Rather than duplicating the file, bld.bat stays the single source and gets copied to build.bat at CI time on Windows.

• RATTLER_CHANNELS array — channels-list includes --override-channels, which rattler-build's CLI doesn't recognize, so it's stripped before use. Expanded into a bash array (instead of a bare $VAR) so each -c <channel> reaches rattler-build as a separate argument — also fixes a shellcheck SC2086 warning.

• Removed usage of conda-verify — it's a conda-build-specific post-build checker; rattler-build validates internally, so it's no longer needed.

• Removed the two guard blocks and the pyproject.toml loop in rattler_recipe.yaml — v1 format must always be valid plain YAML, so Jinja control-flow ({% if %}/{% for %}) isn't supported. The version guard checks are dropped (an invalid override still fails to build, just via a less friendly solver error instead of a custom message), and the dependency list previously generated from pyproject.toml's [build-system] requires is now static — it needs manual updates if those requirements change.

• Added tests: - script: ... block — v1 schema requires an explicit test type; the old test: requires: block installed test deps without running anything, which isn't valid anymore. Added a minimal import/version smoke test

• Replace miniconda with rattler-build action in the build job — rattler-build is a standalone binary with no conda/Python dependency, so building conda packages with it doesn't need a full conda distribution on the runner. The installation takes about 1s

[coveralls]

coverage: 78.494% (+0.003%) from 78.491% — ekomarova:rattler-build-migration into IntelPython:master

[ekomarova]

@antonwolfy @ndgrigorian It looks like I've managed to stabilize GitHub CI, so please take a look at it when you have time. rattler-build wins in terms of build speed and dependency resolution

I would also consider getting rid of installing miniconda for conda_package test pipeline, since rattler-build is standalone and installed fairly quickly. According to my observations, all that miniconda is used for is indexing, searching, installation, and all this supports by rattler and pixi, so migrating the test part to a faster rattler/pixi also makes sense. But this is a separate task that I would not make part of this PR

[antonwolfy]

We need to add run_test.bat and run_test.sh running explicitly, since rattler-build will not automatically do that anymore:

tests:
  # quick smoke checks
  - script:
      - pip check
      - python -c "import dpnp; print(dpnp.__version__)"
      - python -m dpctl -f
    requirements:
      run:
        - pip
  # full suite via the existing scripts
  - script: ${{ "run_test.bat" if win else "run_test.sh" }}
    requirements:
      run:
        - pytest
        - setuptools
        - if: match(python, "<3.14")
          then: scipy

[antonwolfy]

We need to pass --test skip , since we are running tests only in separate dedicated job

[antonwolfy]

It's possible to specify the names of build scripts explicitly in recipe file:

build:
  script:
    file: ${{ "bld.bat" if win else "build.sh" }}

and that step can be dropped then

[antonwolfy]

OVERRIDE_INTEL_IPO is only applicable to Windows

[antonwolfy]

"*/dpnp_backend_c.dll" is only applicable to Windows

[antonwolfy]

It'd be better to update bld.bat also, to use more robust check: if not "%OVERRIDE_INTEL_IPO%"=="", because the default behavior might be changed now a bit (empty string "" rather then undefined env variable)

[antonwolfy]

It seems rattler-build support that on recipe level also. But that can be left for the follow-up.

[antonwolfy]

To reduce the duplication we can define all using build options as build-args in prefix-dev/rattler-build-action

[antonwolfy]

Please populate changelog stating that rattler-build compatible version of recipe has ben added.