Test free-threaded Python (but only on Linux)#2011
Merged
Byron merged 2 commits intogitpython-developers:mainfrom Mar 12, 2025
Merged
Test free-threaded Python (but only on Linux)#2011Byron merged 2 commits intogitpython-developers:mainfrom
Byron merged 2 commits intogitpython-developers:mainfrom
Conversation
EliahKagan
changed the title
EliahKagan
changed the title
See gitpython-developers#2005. Right now, this does not limit by operating system, but that is just to verify that there are no OS-specific 3.13t problems we should know about right now; once that is verified, the macOS and Windows jobs will be removed (excluded) for the time being. The 3.13t jobs added here use `Quansight-Labs/setup-python`, not `actions/setup-python`. The latter also has the ability to use 3.13t since actions/python-versions#319 and actions/setup-python#973 (see also actions/setup-python#771), but no version tag includes this feature yet. It can be used by using `@main` or `@...` where `...` is an OID. The former would risk pulling in other untested features we're no trying to test with, while the latter would not be easy to upgrade automatically as what we have now (we would be deliberately keeping a hash not at any tag that is already not the latest hash on any branch). In contrast, the `Quansight-Labs/setup-python` fork adds this feature while staying up to date with others. When `actions/setup-python` has a release (stable or prerelease) with this feature, we can switch to it. This could probably be done with less code duplication by using a matrix variable for the action to use. Instead, the "Set up Python" step is split in two, with opposite `if` conditions, so that each is capable of being recognized and upgraded by Dependabot if a new major version is released (in case this ends up remaining in place longer than expected).
For now, this omits macOS and Windows from the 3.13t ("threaded")
tests.
The plan in gitpython-developers#2005 is to start without them, and no OS-specific
problems have been identified so far. In particular, in the
previous commit that adds 3.13t without excluding any operating
systems, all tests in the macOS job passed as expected, and the
Windows job had the same failure with the same message as in gitpython-developers#1955,
with no XFAIL changed to XPASS (which, if present, would suggest
GC differences meriting further exploration of 3.13t on Windows).
EliahKagan
added a commit
to EliahKagan/GitPython
that referenced
this pull request
Mar 9, 2026
As discussed in gitpython-developers#2005 and gitpython-developers#2011, we had not been doing this before. Conditions have changed in two relevant ways: - The free-threaded interpreter has been around longer and it sees more use. - The macOS runners are very fast now. The specific motivations for doing this now are: - In view of the condition described in gitpython-developers#2109 and how the change there seems to have helped with it, there's some reason to think *patch* versions of Python sometimes affect GitPython in ways it makes possibly unfounded assumptions about the effect of garbage collection. This mainly affects Windows and it is not specific to free-threaded builds. However, in principle we could also see assumptions violated in tests we think always work on Unix-like operating systems, due to differences in how garbage collection works in free-threaded interpreters. Therefore, the assumption that this only needs to be tested occasionally is not as well founded I assumed when I suggested testing it only on GNU/Linux. - We may add 3.14 jobs to CI soon, and it's useful to be able to see how both free-threaded interpreters work on CI, as well as to confirm for at least a short while that they are continuing to work as expected. This macOS free-threaded interpreter CI jobs could be disabled once more if necessary, or if they're found to make CI complete slower in PRs by even a small amount so long as they don't seem to be surfacing anything.
EliahKagan
added a commit
to EliahKagan/GitPython
that referenced
this pull request
Mar 9, 2026
As discussed in gitpython-developers#2005 and gitpython-developers#2011, we had not been doing this before. Conditions have changed in two relevant ways: - The free-threaded interpreter has been around longer and it sees more use. - The macOS runners are very fast now. The specific motivations for doing this now are: - In view of the condition described in gitpython-developers#2109 and how the change there seems to have helped with it, there's some reason to think *patch* versions of Python sometimes affect GitPython in ways it makes possibly unfounded assumptions about the effect of garbage collection. This mainly affects Windows and it is not specific to free-threaded builds. However, in principle we could also see assumptions violated in tests we think always work on Unix-like operating systems, due to differences in how garbage collection works in free-threaded interpreters. Therefore, the assumption that this only needs to be tested occasionally is not as well founded I assumed when I suggested testing it only on GNU/Linux. - We may add 3.14 jobs to CI soon, and it's useful to be able to see how both free-threaded interpreters work on CI, as well as to confirm for at least a short while that they are continuing to work as expected. This macOS free-threaded interpreter CI jobs could be disabled once more if necessary, or if they're found to make CI complete slower in PRs by even a small amount so long as they don't seem to be surfacing anything.
EliahKagan
added a commit
to EliahKagan/GitPython
that referenced
this pull request
Mar 9, 2026
As discussed in gitpython-developers#2005 and gitpython-developers#2011, we had not been doing this before. Conditions have changed in two relevant ways: - The free-threaded interpreter has been around longer and it sees more use. - The macOS runners are very fast now. The specific motivations for doing this now are: - In view of the condition described in gitpython-developers#2109 and how the change there seems to have helped with it, there's some reason to think *patch* versions of Python sometimes affect GitPython in ways it makes possibly unfounded assumptions about the effect of garbage collection. This mainly affects Windows and it is not specific to free-threaded builds. However, in principle we could also see assumptions violated in tests we think always work on Unix-like operating systems, due to differences in how garbage collection works in free-threaded interpreters. Therefore, the assumption that this only needs to be tested occasionally is not as well founded I assumed when I suggested testing it only on GNU/Linux. - We may add 3.14 jobs to CI soon, and it's useful to be able to see how both free-threaded interpreters work on CI, as well as to confirm for at least a short while that they are continuing to work as expected. This macOS free-threaded interpreter CI jobs could be disabled once more if necessary, or if they're found to make CI complete slower in PRs by even a small amount so long as they don't seem to be surfacing anything.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #2005
See commit messages for details:
@mainor@...where...is an OID) for the3.13tjob, and why that is expressed by splitting the step instead of introducing a new matrix variable.(As elsewhere, due to #2004, the Cygwin test job should be expected to fail here until #2009 is merged. That is not related to the changes here.)