NEW: Migrate recipes to CUDA 13.0

[carterbox]

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.

Test Feedstocks:

• DNM: Test CUDA 13.0 migrator libastra-feedstock#35 Rough edge with Windows binary paths
• NVCOMP Not built from source
• Add CUDA 13 support ucx-split-feedstock#222 (unix only!)
• cupy v13.6.0 cupy-feedstock#314 Rough edge with Windows binary paths

Blocking Issues:

• CUDA 13 not supported in Windows CI setup conda-forge-ci-setup-feedstock#397
• Allow cross compiling for linux-aarch64 with CTK13, now that it is fully available conda-forge-ci-setup-feedstock#395

[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/meta.yaml) and found it was in an excellent condition.

[h-vetinari]

looks pretty good already!

[h-vetinari]

Since we haven't closed the 12.9 migration yet, it would be good to test that the presence of both cuda129.yaml and cuda130.yaml does the right thing.

[h-vetinari]

With the changes to the global zip this becomes a bit harder to test locally, but it's still possible. You need to use the recipe/conda_build_config.yaml from this PR, copy it somewhere (say that file is called cbc), then you can test rerender this migrator (with use_local: true, and the relevant changes to cuda129.yaml if present) using conda smithy rerender -e ../cbc

At first I wanted to use additional_zip_keys: like for the nogil migrator

conda-forge-pinning-feedstock/recipe/migrations/python313t.yaml

Lines 27 to 29 in c456e01

	additional_zip_keys:
	- is_freethreading
	- is_abi3

This would postpone having to modify the global pinning until we close the 13.0 migration. But I wasn't able to get this work, it fails in smithy with

  File "E:\miniforge\envs\builder\Lib\site-packages\conda_smithy\variant_algebra.py", line 191, in op_variant_key_add
    additional_zip_keys_default_values[additional_key] = result[additional_key][0]
                                                         ~~~~~~^^^^^^^^^^^^^^^^
KeyError: 'c_stdlib_version'

Since the question is just when we add c_stdlib_version back to the zip, I just went ahead and did it here. I was able to rerender the pytorch feedstock with these changes, and it did the correct thing.

[h-vetinari]

From my POV, this is good to go

[bdice]

Seems fine to me!

[carterbox]

There's still some bugs in the Windows CUDA 13.0 build for libastra which AFAIK is the only compiled feedstock that this migrator has been tested against. Until we have a few examples of non-redist packages successfully building with the CUDA 13.0 CTK, I'd prefer not to start the migration.

[h-vetinari]

We could try it on some feedstock like libmagma, etc.? Preferably not yet something with lots of expensive CI jobs (e.g. pytorch).

[h-vetinari]

We could try it on some feedstock like libmagma, etc.? Preferably not yet something with lots of expensive CI jobs (e.g. pytorch).

One thing we could do to ease testing of this on feedstocks (due to the zip-changes), is to merge this with paused: true, so that testing this becomes the usual "just manually copy the migrator file and rerender" workflow

[bdice]

Yes, that's a great idea @h-vetinari!

@billysuh7 @carterbox I'd recommend that we go with that approach when we pick this up again on Monday.

[carterbox]

We could try it on some feedstock like libmagma, etc.? Preferably not yet something with lots of expensive CI jobs (e.g. pytorch).

I just tried to build magma, it's not a good test recipe because it doesn't support CUDA 13 yet. It runs into some of the breaking changes at compile time.

[carterbox]

Insert note here about binary path changes on Windows

[h-vetinari]

Do you want to do this before merging the still-paused migration? We could also add that text later.

[carterbox]

No, I don't want to add the note because we may be reverting the path changes on Windows.

[h-vetinari]

LGTM, thanks!

[h-vetinari]

Do you want to do this before merging the still-paused migration? We could also add that text later.

[carterbox]

@conda-forge-admin, please rerender

[conda-forge-admin]

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

I tried to rerender for you, but it looks like there was nothing to do.

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

[h-vetinari]

As discussed in the core call. Let's merge as paused, and figure out the remaining issues before unpausing.