Versioned executables (e.g., python3.13.exe) missing on Windows

[Rongronggg9]

Description:
Versioned executables (e.g., python3.13.exe) are not installed on Windows while python313.dll, python-3.13.2-amd64.exe, and pip3.13.exe are installed. However, this is not the case on Linux or macOS, where versioned executables (or symlinks) are always present. This is inconvenient when using multiple versions at once.

Action version:
v5

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted

Tools version:
I tested 3.9 and 3.13.

Repro steps:

      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: |
            3.9
            3.13

Expected behavior:
Versioned executables (or symlinks) are present on all platforms.

Actual behavior:
Versioned executables (or symlinks) are missing on Windows.

[priya-kinthali]

Hello @Rongronggg9👋,
Thank you for reporting this issue. We will investigate it and get back to you as soon as we have some feedback.

[priya-kinthali]

Hello @Rongronggg9👋,
Based on our investigation, for Windows, the Python executables, such as python-3.13.2.exe (for x86) and python-3.13.2-amd64.exe (for x64), are directly derived from the source code available on python.org and are architecture-specific.

• For Cached Versions (e.g., 3.8.10): Python is pre-installed for both architectures (x86 and x64) on the runner for cached versions. Consequently, .exe files for both architectures are readily available in the tool cache. Please find this run for reference. 


• Non-Cached Versions (e.g., 3.8.1):
Non-cached versions are downloaded and installed for a single architecture based on the default or specified value. When downloading a non-cached version, the action defaults to x64 if no architecture is specified.

  • x64: C:\hostedtoolcache\windows\Python\3.8.1\x64\python-3.8.1-amd64.exe
  • x86: C:\hostedtoolcache\windows\Python\3.8.1\x86\python-3.8.1.exe

We hope this clarifies. Please let us know in case of any further concerns. Thank you!😊

[Rongronggg9]

I am afraid that you misunderstood the issue.

The issue is never about patch-level versioned (e.g., 3.8.10) executables/symlinks, but minor-level versioned (e.g., 3.8) ones. The latter are always present on Linux or macOS. IMHO, it is hard to describe pinning to a patch-level versioned interpreter as a good practice.

You see, when I use setup-python with python-version: |\n 3.9\n 3.13, I need a reliable approach to launch both versions on all supported platforms. For 3.13, I can simply launch python as setup-python automatically sets it as the default interpreter in the current environment. The dilemma comes when I need to launch Python 3.9. I can launch python3.9 on Linux/macOS, but the same thing is missing on Windows. The situation makes the "Specifying multiple Python/PyPy versions" feature hardly useful in platform-matrixed CI workflows.

What's worse, when "Specifying multiple Python/PyPy versions", setup-python does not provide an approach to determine all (instead of only the last one, IIUC) the installed paths or patch-level versions. The only reliable information in my example is minor-level versions.

I am aware that this can be worked around by invoking setup-python in two different steps and capturing their output to get their patch-level versions or installed paths. But fundamentally speaking, this is just a workaround.

setup-python already empowers platform-matrixed CI workflows by setting the default interpreter as the last version specified to make it easy to write unified CI workflows. To make the "Specifying multiple Python/PyPy versions" feature useful, it'd be better if setup-python ensures the presence of versioned executables/symlinks according to the action input (i.e., given the input python-version: |\n 3.9\n 3.13, the presence of python3.9 and python3.13 should be ensured. This is irrelevant to the upstream behavior, but is meant to make setup-python's "Specifying multiple Python/PyPy versions" feature useful in platform-matrixed CI workflows with non-patch-level versions specified.

[priya-kinthali]

Hello @Rongronggg9👋,
Thank you so much for your detailed explanation and thoughtful feedback! We truly value your insights.

We’ll consider this as a feature request and will explore the possibility of implementing this enhancement in the future to ensure consistent availability of versioned executables across platforms. In the meantime, as you rightly suggested, invoking setup-python in two separate steps and capturing the output to retrieve the installed paths is a potential workaround.

Thank you once again for bringing this to our attention!