ENH: update package version to 13.3.1

[conda-forge-admin]

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

I've started a version update as instructed in #195.

I'm currently searching for new versions and will update this PR shortly if I find one! Thank you for waiting!

Fixes #195

[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.

[rwgk]

@acosmicflamingo quick question: the bot updated version to 13.3.1 and the sha256, but left context.number: 2. For a new upstream version I would normally expect the build number to reset to 0. Do you think we should manually adjust that before merging, or is keeping 2 intentional/expected with the new v1/rattler-build setup?

@leofang for visibility

[acosmicflamingo]

Ah right that should've gone to 0 when the version was bumped; my apologies!

[rwgk]

Ah right that should've gone to 0 when the version was bumped; my apologies!

No worries, innovation is always an adventure :-)

I can easily reset that to zero before merging this PR.

You called this out before I think, this job is taking a very long time:

https://github.com/conda-forge/cuda-python-feedstock/actions/runs/26668235358/job/78606076893?pr=196

IIUC you called this out already as expected. Is there a possibility that we can split it up in the future?

[acosmicflamingo]

@rwgk hm that is interesting...with a conda-build run, even if each process builds its own noarch cuda-python package, they all have the same hash (which isn't surprising). I wonder if rattler-build and conda smithy think it'd be more efficient to have one run build cuda-python once and build Python variants of cuda-bindings (which is why it's taking so long), instead of have them all build in parallel, even if it means you are unnecessarily building the noarch package more than once. That's something I could look into when I'm by a computer sometime this weekend.

[leofang]

I wonder if rattler-build and conda smithy think it'd be more efficient to have one run build cuda-python once and build Python variants of cuda-bindings (which is why it's taking so long), instead of have them all build in parallel

It might be possible and if this is true it'd explain my confusion (#183 (comment)). I wouldn't sweat in this PR, though. It can be addressed at a later time.

[acosmicflamingo]

I'll create a ticket and investigate when I have a chance. What a huge bummer that there's huge performance gains in the builds themselves, just for rattler-build to be too clever for its own good here 🥲

[leofang]

I already asked my bot to start analyzing it through the experiment in #198

[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
• github-actions: passed

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

[leofang]

I already asked my bot to start analyzing it through the experiment in #198

I think I fix the parallelization but still am waiting to check if the same hash for the noarch packages would be generated. Feel free to merge this PR as-is.

[acosmicflamingo]

You did!!! Nice find Leo 🤩

[acosmicflamingo]

Wait...no, it failed. Actually, that error was what led me to realize that the noarch hashes differed when I was explicitly adding is_freethreading in the recipe.yaml. But, maybe you're in the right direction 🧐

[acosmicflamingo]

@leofang looking at this, what happens if you use both use_keys and ignore_keys? Does conda smithy render all those variant files but ensure that the hash is the same? Or does one have higher precedence?

[leofang]

Looked into this — use_keys and ignore_keys on the same key cancel out, so the suggestion unfortunately doesn't work for our case.

Both options write to the same variant map in rattler-build, and they're applied in sequence: use_keys inserts first, then ignore_keys unconditionally .retain()s the key out:

https://github.com/prefix-dev/rattler-build/blob/9bf3b3bc314683af2a32b71a495c1e2af634e4de/crates/rattler_build_recipe/src/variant_render.rs#L1384-L1407

// Add use_keys to the variant (forces them to be included even if not referenced)
...
for key in &use_keys {
    if let Some(value) = combination.get(key) {
        variant.insert(key.clone(), value.clone());
    }
}

// Filter out ignore_keys from the variant
...
variant.retain(|key, _| !ignore_keys.contains(key));

Net result for use_keys: [python] + ignore_keys: [python]: python is added, then removed → the per-output variant ends up without python, identical to specifying neither. conda-smithy then reads the rendered output via MetaData.get_used_vars() which just returns build_configuration.variant.keys() — so it doesn't see python either, the intersection of top-level loop vars drops it, and the matrix collapses back to a single serialized job per platform.

There's no two-stage semantics (e.g. "use for matrix, ignore for hash") — both options write to the single variant field that drives both matrix expansion and the build-hash input. The matrix-discovery pass at variant_render.rs#L702-L707 does add use_keys to used_vars to generate the combinations, but the per-output variant assembled later at L1384-L1407 still ends up with python removed by ignore_keys, so all N expanded combinations collapse to one unique variant dict downstream.

So the only ways to get "matrix splits on python, but hash doesn't include python" today are:

1. variant.use_keys: [python] + an explicit build.string that doesn't embed the auto-computed hash — which is what we ended up with in Restore linux64 build parallelization #198 (and is the same pattern conda-forge/root-feedstock uses on its root_cxx_standard noarch output).
2. Upstream a real "matrix-only" vs "hash-only" split in rattler-build's variant model. Probably worth filing as a feature request — it would generalize cleanly to other CFEP-25 feedstocks with mixed noarch + non-noarch outputs.

-- Leo's bot

[leofang]

Confirmed that #198 fixed/restored the parallel builds!