Enable allow-prereleases on all Python installs.

[freakboy3742]

Enable the use of allow-prereleases when setting up Python.

This allows us to use a bare version number for pre-release Python versions, rather than needing to add (and often remove at runtime) the -dev suffix. Given we're about to do a big push of adding 3.14, and removing the -dev suffix from 3.13, it seemed opportune to get this in place.

PR Checklist:

• All new features have been tested
• All new features have been documented
• I have read the CONTRIBUTING.md file
• I will abide by the code of conduct

[rmartin16]

👍🏼

[rmartin16]

Few thoughts reviewing this workflow:

• All the testing of app-build-verify.yml explicitly specifies python-version; this seems unnecessary and should probably just use the default 3.x
• For the Linux System builds, I think we should update app-build-verify.yml to allow the value system for python-version; that would signal app-build-verify.yml to skip actions/setup-python without the caller needing to explicitly specify the version of Python for the runner.

[freakboy3742]

Few thoughts reviewing this workflow:

• All the testing of app-build-verify.yml explicitly specifies python-version; this seems unnecessary and should probably just use the default 3.x

I must be looking at something else, because to my eye, all the tests of app-build-verify (in ci.yml) explicitly set a python version:

• test-verify-apps-briefcase - 3.10
• test-verify-apps-briefcase-template - 3.11
• test-verify-apps-android-templates - 3.11
• test-verify-apps-iOS-templates - 3.11
• test-verify-apps-linux-system-templates - 3.10
• test-verify-apps-appimage-templates - 3.11
• test-verify-apps-flatpak-templates - 3.11
• test-verify-apps-macOS-templates - 3.11
• test-verify-apps-web-templates - 3.11
• test-verify-apps-windows-templates - 3.11

• For the Linux System builds, I think we should update app-build-verify.yml to allow the value system for python-version; that would signal app-build-verify.yml to skip actions/setup-python without the caller needing to explicitly specify the version of Python for the runner.

Agreed this would be a useful feature to add.

To "yes-and" this - should we replace the existing system-python handling? The current handling has a bunch of "if the selected python version is the system python, don't install/do run this step" etc; should we replace that with "if the selected python version is system", and if the user happens to select a version of Python that happens to be the system python, then they get a "normal" python install?

[rmartin16]

I must be looking at something else, because to my eye, all the tests of app-build-verify (in ci.yml) explicitly set a python version:

Right; I'm just saying I think we should not set python-version in ci.yml and instead just let it fallback to the default (i.e. 3.x) specified in app-build-verify.yml.

To "yes-and" this - should we replace the existing system-python handling?

Yeah; this has all grown organically a bit and these simplifications definitely make sense to me.

[freakboy3742]

Right; I'm just saying I think we should not set python-version in ci.yml and instead just let it fallback to the default (i.e. 3.x) specified in app-build-verify.yml.

Ah - agreed, except for keeping one as a token check of the "explicitly asking for a python version" case.

To "yes-and" this - should we replace the existing system-python handling?

Yeah; this has all grown organically a bit and these simplifications definitely make sense to me.

Ok - I've made these two changes - let me know what you think.

[rmartin16]

I was initially confused reading some of the logic...but then I realized this is taking a bit more liberal view of "system" than what I was imagining.

When I think about "system Python", I am referring to the Python that is default and native to the environment. For Linux, this Python is governed by the distributors...but for macOS and Windows, this Python does not exist (or at least not meaningfully). Therefore, if we expand "system Python" to include macOS and Windows in CI, we're really just saying "whatever GitHub ships in the runner" is the "system Python". So, testing against a "system Python" on these platforms doesn't have any analogue in reality.

As another line of reasoning, this also creates a very different definition of "system" for non-Linux platforms. For Linux, we literally want to use the Python installed by the system. Elsewhere, though, we're saying we want a system Python...but really just install a version of GitHub's Python for us to use. Furthermore, we're depending on GitHub to not let this "system Python" be an EOL version at any point.

Philosophy aside...this implementation does have the advantage of simplifying the use of app-build-verify and app-create-verify insofar as allowing callers to just pass system for python-version regardless of the runner OS. If we take my imagined implementation, callers would need to conditionally set python-version to system only when testing native Linux packaging.

For instance, if we consider how Briefcase would need to use app-build-verify:

verify-apps:
  name: Build app
  needs: [ package, package-automation, unit-tests ]
  uses: beeware/.github/.github/workflows/app-build-verify.yml@main
  with:
    python-version: ${{ matrix.python-version }}
    runner-os: ${{ matrix.runner-os }}
    framework: ${{ matrix.framework }}
  strategy:
    fail-fast: false
    matrix:
      framework: [ "toga", "pyside6", "pygame", "console" ]
      runner-os: [ "macos-12", "macos-14", "ubuntu-latest", "windows-latest" ]
      include:
        - runner-os: "ubuntu-latest"
          python-version: "system"

So, long-winded as usual...but personally, I think I lean towards a more limited definition of "system" where we're literally just talking about /usr/bin/python3. Therefore, the value of system for python-version would only mean "do not run actions/setup-python"....and this is really only appropriate for the Ubuntu runners. Thoughts?

[freakboy3742]

So, long-winded as usual...but personally, I think I lean towards a more limited definition of "system" where we're literally just talking about /usr/bin/python3. Therefore, the value of system for python-version would only mean "do not run actions/setup-python"....and this is really only appropriate for the Ubuntu runners. Thoughts?

That's where I started; the problem is that it fall apart on matrix builds because you can't pass "system" into a macOS/Windows build in a matrix.

I guess the real question here is whether it makes more sense to raise an error, or fall back to a "recent version". I've used the fallback, using the python3 that is available in the CI platform; but there's an argument to be made that "3.x" might be a more predictable interpretation. I agree that it's a little weird in the intepretation of "system"; but it's a strict addition of behavior ("system" on macOS/Windows ~= "3.x"), and that interpretation doesn't not make sense given there's no other meaningful interpretation of system (unless you want to get into "Xcode ships with 3.9" and "Windows ships with a store shim that will install 3.x"... but a strict "3.x" makes more sense to me)

Having a fallback doesn't preclude the sort of usage you've described, either. You could still define a default python version of "3.12", and override the Python to "system" for a specific Linux build. Your specific example workflow needs one more detail, as the macOS/Windows cases won't define a value for python-version, but that's easy to add with either a default includes: value, or a ``${{ matrix.python-version || '3.12' }}` when defining the python version.

The other detail worth flagging; app-create-verify does need to install Python, even on Linux, because otherwise it tries to install dependencies into the system python, falls back to a user install and fails. Open to suggestions to any fixes or workarounds on this one; but that's also the pre-existing behavior.

So - do we keep the "working fallback", or go back to "raise an error if you use 'system' on macOS/Windows", and modify the handful of matrix test cases to avoid the error?

[rmartin16]

So - do we keep the "working fallback", or go back to "raise an error if you use 'system' on macOS/Windows", and modify the handful of matrix test cases to avoid the error?

I mostly just want to avoid any behavior where passing system for python-version has a valid meaning for macOS and Windows; so, I think that should be a failure mode.

Your specific example workflow needs one more detail, as the macOS/Windows cases won't define a value for python-version, but that's easy to add with either a default includes: value, or a ${{ matrix.python-version || '3.12' }} when defining the python version.

In my example, I was intending the choice of Python version be deferred to app-build-verify since it should default to 3.x in absence of a value.

The other detail worth flagging; app-create-verify does need to install Python, even on Linux, because otherwise it tries to install dependencies into the system python, falls back to a user install and fails. Open to suggestions to any fixes or workarounds on this one; but that's also the pre-existing behavior.

I think your solution is fine...but as with app-build-verify, I don't think system should have a meaning on macOS and Windows.

As an alternative, I suppose, we could expand a bit what we're trying to do. My initial thought was "let's embed this whole Python version pinning within the beeware/.github workflows" because the callers don't actually care. However, we could just take this a step further and use a value like resolve for python-version; in this way, the callers would then be explicitly deferring to the beeware/.github workflows to figure out the correct Python to run the workflow with.