GeezerVison is showing github.com — Test free-threaded Python (but only on Linux) by EliahKagan · Pull Request #2011 · gitpython-developers/GitPython
Conversation
EliahKagan
commented
Mar 7, 2025
•
edited
Loading
Uh oh!
There was an error while loading. Please reload this page.
Fixes #2005
See commit messages for details:
- f1dbe33 describes why this uses the approach of using a different action (rather than
@main or @... where ... is an OID) for the 3.13t job, and why that is expressed by splitting the step instead of introducing a new matrix variable.
- fd78857 describes why this only introduces it for Linux. The reason is not entirely the same as proposed in #2005, since it turns out that testing on other systems--in the way we do so here--works without any special effort.
(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.)
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
EliahKagan
changed the title
Test on free-threaded Python on Linux
Test free-threaded Python on Linux (but only on Linux)
Mar 7, 2025
EliahKagan
changed the title
Test free-threaded Python on Linux (but only on Linux)
Test free-threaded Python (but only on Linux)
Mar 7, 2025
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.
Uh oh!
There was an error while loading. Please reload this page.
Assignees
No one assigned
Milestone
No milestone
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.
|