Python 3.13 standard and free-threaded versions cannot be available at the same time on Windows machines

[RobPasMue]

Description:
Originally raised in crate-py/rpds#110

It looks like whenever you request installing Python 3.13 on standard and free-threaded mode at the same time, on Windows runners... something wrong is going on. From what I've experienced, only the last of the two requested Python 3.13 installations remains available for the workflow. It seems like there might be some conflicts in the installation and they can not coexist currently. It would be great if we could have access to both installations freely.

Action version:
v5

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted

Tools version:
3.13 (standard and free-threaded)

Repro steps:
I had to submit this PR (crate-py/rpds#111) to solve the originally posted issue. One can see on the logs for the last release (where it was attempted to install both 3.13 and 3.13t) that the installation went through (https://github.com/crate-py/rpds/actions/runs/12125451619/job/33805632758) for both of them (3.13 first, and then 3.13t). However, when using the PyO3/maturin-action@v1 action and selecting both interpreters (3.13 and 3.13t), the former did not get executed - most probably because it couldn't find it.

Expected behavior:
I would expect both interpreters to be available.

Actual behavior:
Only the latter is available of the 2 3.13 versions requested.

[RobPasMue]

Please let me know if there is any additional information you need. I might be wrong in some of my assumptions - maybe the error is not in this repo and somewhere else... but, following @Julian's recommendation, we thought it was worth raising it here.

[ngoldbaum]

I don't think I realized this when I was working on this for NumPy because NumPy sets up each python individually in its own CI job.

I think this might just be how we have to make things work on Windows? Since if you do simultaneously install both, they share a site-packages folder, which seems bad as well: python/cpython#127294 (comment)

We can also look at installing free-threaded python using the nuget installers.

ping @FFY00 maybe you have some insight into whether there's a better way for this action to handle the windows free-threaded packaging situation

[FFY00]

I think installing via nuget should probably be the way to go, if possible. As documented in the linked issue, the regular Windows installers introduce some issues, and limitations.