use different name for CUDA 11.8 opt-in migrator

[h-vetinari]

I just noticed a problem with #7472 / #7432: we ended up using the exact same filename for the migrator (cuda118.yaml) as the original CUDA 11.8 migration (c.f. #5340, #4834)

The detection mechanism in the migrator infrastructure whether a given feedstock has been migrated is based on that filename, and consequently, it thinks that ~90 feedstocks have opted into re-adding cuda 11.8 -- though this is just because it's reusing the "done" status from the old migrator, not because those 90 feedstocks still have the migrator file present.

By reusing the name, we effectively make it impossible for #7431 to take effect on feedstocks that still have the old migrator lying around. Luckily, there's currently just two that are affected (arrow was intentional, and prismatic_split is archived):

• https://github.com/conda-forge/hoomd-dlext-feedstock/blob/main/.ci_support/migrations/cuda118.yaml
• https://github.com/conda-forge/openmmtorchplugin-feedstock/blob/main/.ci_support/migrations/cuda118.yaml

So overall, it's probably fine to keep using the old migrator filename. The only real consequence is that the status page becomes useless, but that's not such a big deal. If however people do want to fix this, we should do it soon, before any more feedstocks start using the migrator as instructed in the announcement.

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

[leofang]

conda-forge/cupy-feedstock#309 shows how to use this PR and #7476 together to enable support for CUDA 12.9 & 11.8. I don't think we should change the filename because the announcement points to it. Coming from there, the only difficulty that caused me to struggle is use_local: true is missing.

[h-vetinari]

Coming from there, the only difficulty that caused me to struggle is use_local: true is missing.

Given that it's a real, live migrator (even if paused), the use_local: true should normally not be necessary...? 🤔

What did you observe?

(if you're talking about cuda129.yaml, then yes it's necessary, but only until #7476 is merged)

[leofang]

What did you observe?

The CI pipelines for the migrator that does not have use_local: true would disappear. I don't think paused matters in individual feedstocks.

[h-vetinari]

I don't think paused matters in individual feedstocks.

What matters is whether a migrator with the same filename is found in content of the latest conda-forge-pinning. Paused migrators that are present there will still take effect.

The CI pipelines for the migrator that does not have use_local: true would disappear.

As I said, I suspect strongly that this was only the cast for cuda129.yaml; cuda118.yaml shouldn't need it¹. Now that #7476 is merged, you can retry again to remove use_local: true in both, and it should work (in a few minutes, when the new pinning is through the CDN).

Footnotes

1. I regularly use paused migrators to bootstrap the components of the abseil migration before starting it; I know this works. ↩

[h-vetinari]

So overall, it's probably fine to keep using the old migrator filename. The only real consequence is that the status page becomes useless, but that's not such a big deal.

closing as obsolete; the accuracy of the info on the status page is not that important