As discussed ingitpython-developers#2005 andgitpython-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 ingitpython-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 oncemore if necessary, or if they're found to make CI complete slowerin PRs by even a small amount so long as they don't seem to besurfacing anything.

The status of 3.14 is now effectively the same as the status of3.13 when we started testing it ingitpython-developers#1990.This doesn't enable it on Windows yet, for the same reason that westill have not yet enabled regular CI tests of 3.13 on Windows. Itis hoped that 3.13 and 3.14 can be gotten fully working on Windows(rather than just mostly working, we think) soon; these exclusionsare meant to be temporary.Both the usual GIL interpreter and the free-threaded (nogil)intepreters are tested. See the immediately preceding commit on thetradeoffs involved in doing so.

Except on Python 3.8, where 7.1.2 is the latest compatible version.(This would also apply to versions lower than 3.8, but we don'tsupport building docs on any such versions, even though we stillsupport installing and using GitPython on 3.7.)The reason for this change is that, starting in Python 3.14, the`ast` module no longer has a `Str` member. String literals areinstead represented by `ast.Constant` (and the type of the valuecan be checked to see if it's a string). But versions of `sphinx`lower than 7.2.0 rely on `ast.Str` being present. This causes ourdocumentation not to be able to build at all starting in 3.14. Themost important part of the error is:    Exception occurred:      File "/opt/hostedtoolcache/Python/3.14.3/x64/lib/python3.14/site-packages/sphinx/pycode/__init__.py", line 141, in analyze        raise PycodeError(f'parsing {self.srcname!r} failed: {exc!r}') from exc    sphinx.errors.PycodeError: parsing '/home/runner/work/GitPython/GitPython/git/index/base.py' failed: AttributeError("module 'ast' has no attribute 'Str'")An example of code in `sphinx` 7.1.2 that will cause such an erroris `sphinx.pycode.parser.visit_Expr` implementation, which starts:if (isinstance(self.previous, (ast.Assign, ast.AnnAssign)) andisinstance(node.value, ast.Str)):In `sphinx` 7.2.0, `sphinx.pycode.parser.visit_Expr` insteadbegins:    if (isinstance(self.previous, (ast.Assign, ast.AnnAssign)) and            isinstance(node.value, ast.Constant) and isinstance(node.value.value, str)):This upgrades `sphinx` on all versions of Python where it *can* beinstalled at a version that has such changes -- rather than only onPython 3.14 -- for consistency, including consistency in possibleminor variations in generated documentation that could otherwisearise from using different versions of `sphinx` unnecessarily.As for why this upgrades to 7.4.7 rather than only to 7.2.0, that'sbecause they are both compatible with the same versions of Python,and as far as I know there's no reason to prefer an earlier versionwithin that range.Although GitPython still supports being installed and run on Python3.8 (and even on Python 3.7), it has been end-of-life (i.e., nolonger supported by the Python Software Foundation) for quite sometime now. That the version of Sphinx used to build documentationwill now be different on Python 3.8 than other versions is a reasonnot to use Python 3.8 for this purpose, but probablly already notthe most important reason.The change here is conceptually similar to, but much simpler than,the change ingitpython-developers#1954, which upgraded Sphinx to 7.1.2 on all Pythonversions GitPython suppports other than Python 3.7. The subsequentchange ingitpython-developers#1956 of removing support for building the GitPythondocumentation on Python 3.7 may be paralleled for 3.8 shortly.

This discontinues supporting building documentation on Python 3.8.It does not affect installing or running GitPython on Python 3.8(except when the `doc` extra is used, but this is only used forbuilding documentation). The reason is that it is no longerpossible to use the same version of Sphinx on Python 3.8 as on themost recent supported versions of Python, because Python 3.14 nolonger has `ast.Str` (using `str.Constant` for string literalsinstead), which causes the oldest version of `sphinx` that runs onPython 3.14 to be `sphinx` 7.2.0, while the newest version that isinstallable on Python 3.8 is `sphinx` 7.1.2.The immediately preceding commit changes the requirements for the`doc` extra to specify a newer `sphinx` version for Python 3.9 andlater. This can't be done on Python 3.8. Because there can besubtle differences in documentation generated with different`sphinx` versions, and because Python 3.8 has been end-of-life forsome time, it is not really worth carrying conditional dependenciesfor the `sphinx` version in `doc/requirements.txt`.Note that, while it is probably not a very good idea to useGitPython (or anything) on Python 3.8 since it is end-of-life, thischange does not stop supporting installing GitPython on that or anyother version it has been supporting. Installing and usingGitPython remains supported all the way back to Python 3.7 at thistime. This only affects the `doc` extra and its requirements.This change is analogous to the change made ingitpython-developers#1956, whichfollowed up on the change ingitpython-developers#1964 in the same way this changefollows up on the change in the immediately preceding commit.

This effectively revertsd1ab2e4. It doesn't look like any problemsarose, and contrary to my guess, the additional jobs do actuallymake the checks that we intend to be blocking for PRs take longer,even after all non-macOS checks have completed.

CopilotAI left a comment