Enable allow-prereleases on all Python installs. #172
Conversation
There was a problem hiding this comment.
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?
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 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? |
I mostly just want to avoid any behavior where passing
In my example, I was intending the choice of Python version be deferred to
I think your solution is fine...but as with 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 |
👍 I can live with that, especially considering...
... this. I forgot that the workflow had a fallback value at the input level.
I've modified the implementation to take this approach.
I think I'd rather stick to the side of "explicit is better than implicit" - I'm not sure we reliably have enough context on the |
| uses: actions/[email protected] | ||
| with: | ||
| python-version: ${{ inputs.python-version }} | ||
| python-version: ${{ inputs.python-version || '3.x' }} |
There was a problem hiding this comment.
By way of explanation: It appears "with: ''" is passed through as a literal empty string, rather than falling back to a default, so we need to provide the default as a fallback here, as well (same for the create-verify analog).
Will do... however, I don't think there's as many as I originally thought. Briefcase and the linux system template, obviously... but the other Linux templates don't need it... what else am I missing? |
|
I think the explicit use of So, looks like just |
Good catch - I've pushed a PR for that one as well. The others all look like either explicit RTD configs, explicit configs in this repo, PR's I've already submitted, or Toga configs that need to be explicitly 22.04. |
Enable the use of
allow-prereleaseswhen 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
-devsuffix. 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: