Fixed cuda pinning for cuda and pytorch

[das-intensity]

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.

Currently the cuda and pytorch pins allow cuda versions to based on what's default. E.g. when building version:

linux_64_c_compiler_version13cuda_compilercuda-nvcccuda_compiler_version12.6cxx_compiler_version13python3.10.____cpython

it ends up with deps like:

    cuda-cudart:                 12.8.90-h5888daf_1                   conda-forge
    cuda-cudart-dev:             12.8.90-h5888daf_1                   conda-forge
    pytorch:                     2.6.0-cuda126_mkl_py310_hb403307_302 conda-forge

which makes it incompatible with the very cuda 12.6 it's supposed to be using in this build, e.g.

$ conda create -n pt2.6-sparse-mismatch conda-forge::python=3.10 conda-forge::cuda-runtime=12.6 conda-forge::pytorch=2.6.0=cuda* conda-forge::pytorch_sparse --dry-run
...
   ├─ pytorch_sparse 0.6.18 would require
   │  └─ cuda-cudart >=12.8.57,<13.0a0 , which conflicts with any installable versions previously reported;

The deps should be (and is after this patch when testing locally):

    cuda-cudart:                 12.6.77-h5888daf_0                   conda-forge
    cuda-cudart-dev:             12.6.77-h5888daf_0                   conda-forge
    pytorch:                     2.6.0-cuda126_mkl_py310_hb403307_302 conda-forge

[das-intensity]

@conda-forge-admin, please rerender

[conda-forge-admin]

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

I failed to even lint the recipe, probably because of a conda-smithy bug 😢. This likely indicates a problem in your meta.yaml, though. To get a traceback to help figure out what's going on, install conda-smithy and run conda smithy recipe-lint --conda-forge . from the recipe directory. You can also examine the workflow logs for more detail.

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

[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 pinnnings.
• 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/14012872036. Examine the logs at this URL for more detail.}

[das-intensity]

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

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

For recipe/meta.yaml:

• ℹ️ The recipe is not parsable by parser conda-souschef (grayskull). This parser is not currently used by conda-forge, but may be in the future. We are collecting information to see which recipes are compatible with grayskull.
• ℹ️ 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.
• ℹ️ top-level output has some malformed specs:

• In section build: `pytorch ==cuda
• In section host: `pytorch ==cuda
• In section run_constrained: pytorch =*=cuda* Requirement spec fields should always be space-separated to avoid known issues in conda-build. For example, instead of name =version=build, use name version.* build`.

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

[h-vetinari]

which makes it incompatible with the very cuda 12.6 it's supposed to be using in this build, e.g.

$ conda create -n pt2.6-sparse-mismatch conda-forge::python=3.10 conda-forge::cuda-runtime=12.6 conda-forge::pytorch=2.6.0=cuda* conda-forge::pytorch_sparse --dry-run
...
   ├─ pytorch_sparse 0.6.18 would require
   │  └─ cuda-cudart >=12.8.57,<13.0a0 , which conflicts with any installable versions previously reported;

Why do you want to pin cuda-runtime? Things work without this, just tested with

CONDA_OVERRIDE_CUDA=12.6 mamba install python=3.10 pytorch=2.6.0=cuda* pytorch_sparse

which resolves successfully.

Please open an issue to discuss whatever problem you're encountering this PR is not correct.
resolves correctly for me

[h-vetinari]

ok, I see the problem now. We just need to add a pinned cuda-version to host.

[das-intensity]

@conda-forge-admin, please rerender

[das-intensity]

@conda-forge-admin, please rerender

[das-intensity]

@h-vetinari thanks for bearing with me while I upskill on conda maintenance, sorry this was a bit of a mess

[h-vetinari]

Thanks!

[conda-forge-admin]

Hi! This is the friendly conda-forge automerge bot!

I considered the following status checks when analyzing this PR:

• linter: passed
• azure: passed

Thus the PR was passing and merged! Have a great day!