Bump python app

[sicheste]

Using setup-python v5 and Python 3.13.

Pre-requisites

• Prior to submitting a new workflow, please apply to join the GitHub Technology Partner Program: partner.github.com/apply.

---

Please note that at this time we are only accepting new starter workflows for Code Scanning. Updates to existing starter workflows are fine.

---

Tasks

For all workflows, the workflow:

• Should be contained in a .yml file with the language or platform as its filename, in lower, kebab-cased format (for example, docker-image.yml). Special characters should be removed or replaced with words as appropriate (for example, "dotnet" instead of ".NET").
• Should use sentence case for the names of workflows and steps (for example, "Run tests").
• Should be named only by the name of the language or platform (for example, "Go", not "Go CI" or "Go Build").
• Should include comments in the workflow for any parts that are not obvious or could use clarification.
• Should specify least privileged permissions for GITHUB_TOKEN so that the workflow runs successfully.

For CI workflows, the workflow:

• Should be preserved under the ci directory.
• Should include a matching ci/properties/*.properties.json file (for example, ci/properties/docker-publish.properties.json).
• Should run on push to branches: [ $default-branch ] and pull_request to branches: [ $default-branch ].
• Packaging workflows should run on release with types: [ created ].
• Publishing workflows should have a filename that is the name of the language or platform, in lower case, followed by "-publish" (for example, docker-publish.yml).

For Code Scanning workflows, the workflow:

• Should be preserved under the code-scanning directory.
• Should include a matching code-scanning/properties/*.properties.json file (for example, code-scanning/properties/codeql.properties.json), with properties set as follows:
  • name: Name of the Code Scanning integration.
  • creator: Name of the organization/user producing the Code Scanning integration.
  • description: Short description of the Code Scanning integration.
  • categories: Array of languages supported by the Code Scanning integration.
  • iconName: Name of the SVG logo representing the Code Scanning integration. This SVG logo must be present in the icons directory.
• Should run on push to branches: [ $default-branch, $protected-branches ] and pull_request to branches: [ $default-branch ]. We also recommend a schedule trigger of cron: $cron-weekly (for example, codeql.yml).

Some general notes:

• This workflow must only use actions that are produced by GitHub, in the actions organization, or
• This workflow must only use actions that are produced by the language or ecosystem that the workflow supports. These actions must be published to the GitHub Marketplace. We require that these actions be referenced using the full 40 character hash of the action's commit instead of a tag. Additionally, workflows must include the following comment at the top of the workflow file:

  # This workflow uses actions that are not certified by GitHub.
  # They are provided by a third-party and are governed by
  # separate terms of service, privacy policy, and support
  # documentation.
  

• Automation and CI workflows should not send data to any 3rd party service except for the purposes of installing dependencies.
• Automation and CI workflows cannot be dependent on a paid service or product.

[sicheste]

Regarding the variables:
I've checked some other files. Have not seen that it was done like this somehwere. For example the android, ant and maven templates are using the version number in the step name and for the version requirement. But always explicitly written. So yes, technically a considerable idea, but have not seen that it is done somewhere else like this.

Using Python 3.12 instead of 3.13 makes sense and I have changed.

[cclauss]

Suggested change

	python-version: "3.13"
	python-version: "3.x"

https://devguide.python.org/versions/#supported-versions
Testing on the latest version of Python may catch new language incompatibilities before most users notice them.

[reactive-firewall]

Plea for Pinning an exact version

I'll also re-iterate what I previously marked knitpicky as it now directly applies to this, see below:

Consider Python 3.12 might be more appropriate than 3.13 for GHA

Tip

knit-picky or out-of-scope:
Looks like version 3.12 will be the cached version (while 3.13 is the
latest it will probably be slower for some GitHub Actions)
see actions/runner-images#10636
and note the cached versions for python.

Should still work though; Just slightly slower.

In conclusion; pick one (exactly one):

• 3.12 - for tuned value based on GitHub Action's runners.
• 3.13 - the latest available version of Python as per your link; "Should still work though; Just slightly slower" due to not being cached.
• any other less current value in the form defined by the actions/setup-pythonv@5 (3.9.20|3.10|3.11) (included for completeness)
• any invalid version - fall-back to GHA image default installed version. (included for completeness)

Important

This is not to say your rational is wrong, (only the suggested implementation is sub-optimal)

To also implement checking for the latest version please refer to this guide

or as code:

# Rest of config is unchanged
  - uses: actions/setup-python@v5
    with:
      # Version range or exact version of Python or PyPy to use, using SemVer's version range syntax. Reads from .python-version if unset.
      python-version: '3.13'
      # Check every time for updates? 
      check-latest: true

[sicheste]

I like the idea using a cached Python version by default. So I switched to 3.12.

[sicheste]

In python-publish it is given with 3.x. So would not be the first template when setting it to .x here.

[reactive-firewall]

In python-publish it is given with 3.x. So would not be the first template when setting it to .x here.

Oops 🙊

My oversight; Correction: it is a runtime error, not a syntax error. I'll remove the incorrect and confusing phrasing from my previous comment.

For those curious, my full rational,

TL;DR

This gave me pause, at first, as you are quite correct, many (e.g. python-publish, and even the GitHub guides use 3.x all over, and only sometimes do they document why). After some digging all I could find was:

name: Python package

on: [push]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4
      - name: Set up Python
        # This is the version of the action for setting up Python, not the Python version.
        uses: actions/setup-python@v5
        with:
          # Semantic version range syntax or exact version of a Python version
          python-version: '3.x'
          # Optional - x64 or x86 architecture, defaults to x64
          architecture: 'x64'
      # You can test your matrix by printing the current Python version
      - name: Display Python version
        run: python -c "import sys; print(sys.version)"

which makes sense if you are familiar with Semantic Version range syntax which boils down to almost the same thing as I expected (e.g. PEP-440 and the current Python packaging version spec)
The notable difference is 3.x is invalid as a Semantic Version but is considered a local version x of version with Major 3

so I checked the code which documents the same thing, (albeit without the example placeholder of 3.x). So I wanted to see what it did with the version, and deep inside the massive dist/index.js of the python-setup action is a function resolveVersionInput() to resolve the input range that would essentially return ['3.x'], from there it is used by the run() function to attempt to download it via the function useCpythonVersion (because 3.x will not match other cases like 'PyPy' etc.) there it finally is parsed (and unless python3.x cpython is already installed, will fail and fall-back on a default of void 0 (e.g. None version), if there is a python3.x installed on the GHA image is most likely the documented default of 3.12) resulting eventually in a harmless runtime-error, and reporting the actually installed version via the output python-version (same name as input) which would currently be 3.12.

In conclusion: 3.x is still not advised, as omitting the value would be preferred to achieve the same behavior;
the original 3.13 should work;
and I still recommend the cached 3.12.

Informative references

• actions/setup-python@v5/dist/index.js - the code.
• using-a-specific-python-version - GitHub guide on python-setup action topic
• python-action and docs
• semantic versioning specification
• semantic versioning reg-Ex - spec recommended way to test version format
• Python versioning specification

---

Summary

In summary: This topic has been thoroughly explored now, I agree with @cclauss that just using the latest stable would be a fine alternative, but not better than the other already mentioned options.

@sicheste 3.12 for leveraging caching in GHAs, looks good, 👍🏻

[sicheste]

Thanks for the long analysis and explanation.

So, now someone can merge it :)

[reactive-firewall]

LGTM 👍🏻

• consistent meta-data and values
• versions are stable and current