ENH: Migrate recipe to v1 format for rattler-build

[acosmicflamingo]

Checklist

• Used a personal fork of the feedstock to propose changes
• Bumped the build number (if the version is unchanged)
• Reset the build number to 0 (if the version changed)
• Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• Ensured the license file is being packaged.

Resolves #122

Allows for building cuda-python-feedstock using very impressive, performant rattler-build. Things to note:

• Tests are more siloed in rattler-build, and the ability to add runtime dependencies during test-time only affects tests run in the script section. Because of this, tests that import a module that depends on numpy was moved to the script section. More info can be found here
• The environment variables that we took for granted in conda-build's meta.yaml are no longer available outside of the actual build scripts. To work around this, I moved the logic that sets CUDA_HOME and LIB from meta.yaml to build_output.sh and build_output.bat.
• Setting pixi in conda-forge.yml is optional, but I figured it'd be welcome since I see that it's used in cuda-python right now
• If variants like is_freethreading aren't actually used in recipe.yaml, conda-smithy will ignore it outright when generating config files in .ci_support. I only realized this when I saw that numpy does something like this in their feedstock.

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipe/recipe.yaml, recipe/meta.yaml) and found some lint.

Here's what I've got...

For recipe/recipe.yaml:

• ❌ There are 1 too many lines. There should be one empty line at the end of the file.

For recipe/recipe.yaml:

• ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
  • For the tests[].python.python_version or tests[].requirements.run section of cuda-python output, you should usually use the pin python_version: ${{ python_min }}.* or python ${{ python_min }}.* for the python_version or python entry.
  • If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).
• ℹ️ The recipe is not parsable by parser conda-recipe-manager. The recipe can only be automatically migrated to the new v1 format if it is parseable by conda-recipe-manager.

For recipe/meta.yaml:

• ❌ There are 1 too many lines. There should be one empty line at the end of the file.

For recipe/meta.yaml:

• ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.
  • For the tests[].python.python_version or tests[].requirements.run section of cuda-python output, you should usually use the pin python_version: ${{ python_min }}.* or python ${{ python_min }}.* for the python_version or python entry.
  • If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).
• ℹ️ The recipe is not parsable by parser conda-recipe-manager. The recipe can only be automatically migrated to the new v1 format if it is parseable by conda-recipe-manager.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/26324884189. Examine the logs at this URL for more detail.}

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/recipe.yaml) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipe/recipe.yaml:

• ℹ️ noarch: python recipes should usually follow the syntax in our documentation for specifying the Python version.

  • For the tests[].python.python_version or tests[].requirements.run section of cuda-python output, you should usually use the pin python_version: ${{ python_min }}.* or python ${{ python_min }}.* for the python_version or python entry.

• If the package requires a newer Python version than the currently supported minimum version on conda-forge, you can override the python_min variable by adding a Jinja2 set statement at the top of your recipe (or using an equivalent context variable for v1 recipes).

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/26465921710. Examine the logs at this URL for more detail.}

[acosmicflamingo]

@conda-forge-admin, please rerender

[acosmicflamingo]

Failures are because I only updated recipe itself; still need to update .github workflow configs to use rattler-build

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-webservice.

I tried to rerender for you but ran into some issues. Please check the output logs of the GitHub Actions workflow below for more details. You can also ping conda-forge/core (using the @ notation) for further assistance or you can try rerendering locally.

The following suggestions might help debug any issues:

• Is the recipe/{meta.yaml,recipe.yaml} file valid?
• If there is a recipe/conda-build-config.yaml file in the feedstock make sure that it is compatible with the current global pinnings.
• Is the fork used for this PR on an organization or user GitHub account? Automated rerendering via the webservices admin bot only works for user GitHub accounts.

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/26348069183. Examine the logs at this URL for more detail.}

[acosmicflamingo]

@conda-forge-admin, please rerender

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe/recipe.yaml) and found it was in an excellent condition.

[acosmicflamingo]

It appears that specifically for cuda-python, a noarch package, it was problematic to reference is_freethreading in recipe.yaml because what ended up happening was that the py314t version of cuda-python would have a different hash when is_freethreading was true and when it was false. This was why the py314t build would not find the package it needed in build-artifacts directory, since the run didn't comprise any other packages. By removing it, conda smithy would render a single linux_64 config file with the expected variant keys:

python:
- 3.10.* *_cpython
- 3.11.* *_cpython
- 3.12.* *_cpython
- 3.13.* *_cp313
- 3.14.* *_cp314
- 3.14.* *_cp314t

That would mean that now all packages would be created in a single build-artifacts directory as we'd expect.

When it was initially added, it was used as a selector and although the recipes I've seen have the 'touch is_freethreading' logic, the recipes were not for no-arch packages. Additionally, they didn't have a test-time dependency on `python ${{ python_min }}.*, which is why they didn't experience the problem.

I got the build to work locally, so I expect that CI will give us all green builds soon enough. Also made sure that the change in the meta.yaml conflict made its way to recipe.yaml in this PR.

[acosmicflamingo]

@kkraus14 all tests are passing now :) Feel free to use the 'auto-merge' label if you have the impression that it'll be a bit of time before CTK 13.3 trickles down to conda

[acosmicflamingo]

I checked conda-forge and saw the 12.9 and 13.3 packages were there, so I figured the dust has settled. I merged latest changes with mine, resolved conflicts, ran conda smithy locally, and pushed it back so everything should be good to for merging.

I imagine it'd be nice to also migrate the recipe from the 12.9 branch to using rattler-build?

[rwgk]

Human-generated part:

I think this is great and we should merge it. Caveat: see my prompt below.

Currently being in charge of the cuda-python 13.3 release series, this is my game plan:

• Merge this PR now, so that we can try it in the next patch release.
• Worst case: we roll it back and try again later. Risk: an hour or so delay in getting the release out.

I think that's an acceptable risk to take.

If things to well here, I'd be in favor of backporting to the 12.9 branch.

---

AI-generated part:

PR 183 Review

Prompt (Cursor GPT-5.5 1M Extra High)

Could you please do a full review of PR 183?

I'm totally not familiar with conda feedstocks. The PR looks great to me. I'm understanding it's a modernization, does that sound right?

Response

No blocking findings. I’d be comfortable treating PR 183 as merge-ready from this review.

Yes, “modernization” is the right read. It migrates the feedstock from legacy recipe/meta.yaml to v1 recipe/recipe.yaml, switches CI/build plumbing to rattler-build, adds pixi tooling, and rerenders the feedstock. It does not bump the upstream CUDA Python version; it bumps the conda build number because the packaging changed.

I checked the risky feedstock bits: split outputs, cuda-python noarch handling, cuda-bindings host/run pins, freethreading/3.14t variants, moved numpy-dependent tests, Windows CUDA_HOME/LIB handling, and prior review comments. The changes look intentional and consistent with the green CI.

Validation I saw:

• PR is clean/mergeable.
• All PR checks pass, including conda-forge linter and full Linux/Windows matrix.
• Local pixi run -e smithy lint reports recipe is in fine form.
• git diff --check origin/main...HEAD reports no whitespace errors.

Residual risk is mainly that this changes the feedstock build toolchain itself, so I would lean on the full CI matrix rather than local intuition. Since that matrix is green, I don’t see a reason to hold it.

[acosmicflamingo]

Human-generated part:

I think this is great and we should merge it. Caveat: see my prompt below.

Currently being in charge of the cuda-python 13.3 release series, this is my game plan:

• Merge this PR now, so that we can try it in the next patch release.
• Worst case: we roll it back and try again later. Risk: an hour or so delay in getting the release out.

I think that's an acceptable risk to take.

If things to well here, I'd be in favor of backporting to the 12.9 branch.

AI-generated part:

PR 183 Review

Prompt (Cursor GPT-5.5 1M Extra High)

Could you please do a full review of PR 183?

I'm totally not familiar with conda feedstocks. The PR looks great to me. I'm understanding it's a modernization, does that sound right?

Response

No blocking findings. I’d be comfortable treating PR 183 as merge-ready from this review.

Yes, “modernization” is the right read. It migrates the feedstock from legacy recipe/meta.yaml to v1 recipe/recipe.yaml, switches CI/build plumbing to rattler-build, adds pixi tooling, and rerenders the feedstock. It does not bump the upstream CUDA Python version; it bumps the conda build number because the packaging changed.

I checked the risky feedstock bits: split outputs, cuda-python noarch handling, cuda-bindings host/run pins, freethreading/3.14t variants, moved numpy-dependent tests, Windows CUDA_HOME/LIB handling, and prior review comments. The changes look intentional and consistent with the green CI.

Validation I saw:

• PR is clean/mergeable.
• All PR checks pass, including conda-forge linter and full Linux/Windows matrix.
• Local pixi run -e smithy lint reports recipe is in fine form.
• git diff --check origin/main...HEAD reports no whitespace errors.

Residual risk is mainly that this changes the feedstock build toolchain itself, so I would lean on the full CI matrix rather than local intuition. Since that matrix is green, I don’t see a reason to hold it.

Thanks! Glad that Cursor agrees. Lots of the boilerplate changes in this PR came from conda smithy responding to conda-forge.yml. To create recipe.yaml, I used a tool called conda-recipe-manager (details here) that successfully migrated most of the changes. I then went line by line and polished up what the tool wasn't able to convert, so as intimidating as the PR looks, the risk as the agent found is on the lower-risk side (and I also looked at other recipes like numpy feedstock, scikit-learn feedstock, and even this amazing tool to make sure I was doing everything right).

[acosmicflamingo]

Goes without saying @kkraus14 provided lots of helpful feedback as well :)

[rwgk]

A patch release is coming soon. Merging now, JIC the system here needs a little time to catch up.

[acosmicflamingo]

@rwgk Thanks! 🙇🏽‍♂️

[leofang]

(Sorry, I was out and did not have time to catch up until now. Left a bunch of comments as @rwgk is preparing the patch release #196.)

[acosmicflamingo]

@leofang its alright! I know you all have been busy with releases. I won't be able to work on adding any changes until maybe tomorrow but I did my best addressing your comments from my small iPhone screen 😎

[leofang]

Thanks, Andres, no worries! Enjoy your weekend, we'll address the open items in #196 at once.