Test free-threaded Python (but only on Linux) by EliahKagan · Pull Request #2011 · gitpython-developers/GitPython

@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 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.