Add python 3.13 migrations

[isuruf]

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.

[conda-forge-webservices]

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.

[beckermr]

This question is for my own curiosity. Do we need the older python 3.6, 3.7, etc. entries in the ordering key still? If so, why?

[isuruf]

This question is for my own curiosity. Do we need the older python 3.6, 3.7, etc. entries in the ordering key still? If so, why?

If there's an old migration file for 3.6 or 3.7 or 3.8, conda-smithy will likely break. It's a fragile part of the code and we should get rid of ordering stuff as we have never used those parts of the code

[beckermr]

Thanks. We needed the ordering stuff for reasons I now forget. Is there an open issue somewhere on this?

[isuruf]

Not that I recall.

[isuruf]

Let's see how this goes

[h-vetinari]

I see that this is paused, so just two questions:

• Shouldn't we use wait_for_migrators: here to queue this behind the regular 3.13?
• In the last core call where this was discussed, you had suggested running the freethreading migrator several months after 3.13. Is that still the plan, or what changed to move it forward so much?

[isuruf]

It's paused for now, but I added it so that we can experiment with it without the need to add the values to cbc. We can unpause after a couple of months maybe.