Test free-threaded Python (but only on Linux) by EliahKagan · Pull Request #2011 · gitpython-developers/GitPython
changed the title
Test on free-threaded Python on Linux
Test free-threaded Python on Linux (but only on Linux)
EliahKagan
changed the title
Test free-threaded Python on Linux (but only on Linux)
Test free-threaded Python (but only on Linux)
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, 2026As 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, 2026As 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, 2026As 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