Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork939
Support Python 3.13 on Windows#1955
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:main
Are you sure you want to change the base?
Uh oh!
There was an error while loading.Please reload this page.
Conversation
96ceb75
tobae27f4
CompareThis is analogous to the 3.7-related CI change in gitdb that waspart ofgitpython-developers/gitdb#114, asto part ofgitpython-developers/smmap#58.Since some tests are not yet passing on 3.13, this does not add3.13 to CI, nor to the documentation of supported versions in`setup.py`. Note that the list there is not enforced; GitPython canalready be installed on Python 3.13 and probably *mostly* works.(Seegitpython-developers#1955for details on other changes that should be made to fully supportrunning GitPython on Python 3.13.)
Sincegitpython-developers#1987, test jobs from `pythonpackage.yml` appear in anunintuitive order, and some show an extra bool matrix variable intheir names while others don't (this corresponds to `experimental`,which was always set to some value, but was set in different ways).This fixes that by:- Listing all tested versions, rather than introducing some in an `include` key. (The `include:`-introduced jobs didn't distinguish between originally-present matrix variables and those that are introduced based on the values of the original ones.)- Replacing `os` with `os-type`, which has only the first part of the value for `runs-on:` (e.g., `ubuntu`), and adding `os-ver` to each matrix job, defaulting it to `latest`, but using `22.04` for Python 3.7 on Ubuntu.This should also naturally extend to adding 3.13, with or withoutsetting `continue-on-error` to temporarily work around the problemsobseved ingitpython-developers#1955, but nothing 3.13-related is done in this commit.
As this is being integrated, Python 3.13 is no longer a releasecandidate, but this marks it experimental since that might also beused temporarily to prevent some of the failures mentioned ingitpython-developers#1955from failing the workflow.But right now this allows the workflow to fail.
Sincegitpython-developers#1987, test jobs from `pythonpackage.yml` appear in anunintuitive order, and some show an extra bool matrix variable intheir names while others don't (this corresponds to `experimental`,which was always set to some value, but was set in different ways).This fixes that by:- Listing all tested versions, rather than introducing some in an `include` key. (The `include:`-introduced jobs didn't distinguish between originally-present matrix variables and those that are introduced based on the values of the original ones.)- Replacing `os` with `os-type`, which has only the first part of the value for `runs-on:` (e.g., `ubuntu`), and adding `os-ver` to each matrix job, defaulting it to `latest`, but using `22.04` for Python 3.7 on Ubuntu.This should also naturally extend to adding 3.13, with or withoutsetting `continue-on-error` to temporarily work around the problemsobseved ingitpython-developers#1955, but nothing 3.13-related is done in this commit.
As this is being integrated, Python 3.13 is no longer a releasecandidate, but this marks it experimental since that might also beused temporarily to prevent some of the failures mentioned ingitpython-developers#1955from failing the workflow.But right now this allows the workflow to fail.
It is specifically that combination that breaks some things. Theunderlying cause is a change in `isabs` to correctly report thatpaths on Windows that start with `\` that is not part of aconstruction such as `\\?\` are not absolute paths. (Seegitpython-developers#1955 andlinks therein.) The change to `isabs` starts in 3.13, and it isonly applicable to Windows, so only that combination is affected.
Sincegitpython-developers#1987, test jobs from `pythonpackage.yml` appear in anunintuitive order, and some show an extra bool matrix variable intheir names while others don't (this corresponds to `experimental`,which was always set to some value, but was set in different ways).This fixes that by:- Listing all tested versions, rather than introducing some in an `include` key. (The `include:`-introduced jobs didn't distinguish between originally-present matrix variables and those that are introduced based on the values of the original ones.)- Replacing `os` with `os-type`, which has only the first part of the value for `runs-on:` (e.g., `ubuntu`), and adding `os-ver` to each matrix job, defaulting it to `latest`, but using `22.04` for Python 3.7 on Ubuntu.This should also naturally extend to adding 3.13, with or withoutsetting `continue-on-error` to temporarily work around the problemsobseved ingitpython-developers#1955, but nothing 3.13-related is done in this commit.
As this is being integrated, Python 3.13 is no longer a releasecandidate, but this marks it experimental since that might also beused temporarily to prevent some of the failures mentioned ingitpython-developers#1955from failing the workflow.But right now this allows the workflow to fail.
It is specifically that combination that breaks some things. Theunderlying cause is a change in `isabs` to correctly report thatpaths on Windows that start with `\` that is not part of aconstruction such as `\\?\` are not absolute paths. (Seegitpython-developers#1955 andlinks therein.) The change to `isabs` starts in 3.13, and it isonly applicable to Windows, so only that combination is affected.
But not Windows yet (gitpython-developers#1955).
As this is being integrated, Python 3.13 is no longer a releasecandidate, but this marks it experimental since that might also beused temporarily to prevent some of the failures mentioned ingitpython-developers#1955from failing the workflow.But right now this allows the workflow to fail.
It is specifically that combination that breaks some things. Theunderlying cause is a change in `isabs` to correctly report thatpaths on Windows that start with `\` that is not part of aconstruction such as `\\?\` are not absolute paths. (Seegitpython-developers#1955 andlinks therein.) The change to `isabs` starts in 3.13, and it isonly applicable to Windows, so only that combination is affected.
df91dfd
to65ff35f
CompareAs this is being integrated, Python 3.13 is no longer a releasecandidate, but this marks it experimental since that might also beused temporarily to prevent some of the failures mentioned ingitpython-developers#1955from failing the workflow.But right now this allows the workflow to fail.
It is specifically that combination that breaks some things. Theunderlying cause is a change in `isabs` to correctly report thatpaths on Windows that start with `\` that is not part of aconstruction such as `\\?\` are not absolute paths. (Seegitpython-developers#1955 andlinks therein.) The change to `isabs` starts in 3.13, and it isonly applicable to Windows, so only that combination is affected.
The experiment 3.13 Windows job recently started getting `runs-on`set to `windows-` rather than `windows-latest` (causing it to blockindefinitely waiting on a self-hosted runner with `windows-` as alabel). I don't know why this happens, since it looks like it didnot happen before rebasing from65ff35f to6060afd, but it happenswhen force-pushing back to that OID from before the rebase. Thisusually indicates a change in the runner software (or some otherpart of the GHA infrastructure), but it could be that it happenedbefore and went unnoticed (then looked like a failure but wasactually a cancellation?).
For now, this omits macOS and Windows from the 3.13t ("threaded")tests.The plan ingitpython-developers#2005 is to start without them, and no OS-specificproblems have been identified so far. In particular, in theprevious commit that adds 3.13t without excluding any operatingsystems, all tests in the macOS job passed as expected, and theWindows job had the same failure with the same message as ingitpython-developers#1955,with no XFAIL changed to XPASS (which, if present, would suggestGC differences meriting further exploration of 3.13t on Windows).
For now, this omits macOS and Windows from the 3.13t ("threaded")tests.The plan ingitpython-developers#2005 is to start without them, and no OS-specificproblems have been identified so far. In particular, in theprevious commit that adds 3.13t without excluding any operatingsystems, all tests in the macOS job passed as expected, and theWindows job had the same failure with the same message as ingitpython-developers#1955,with no XFAIL changed to XPASS (which, if present, would suggestGC differences meriting further exploration of 3.13t on Windows).
For now, this omits macOS and Windows from the 3.13t ("threaded")tests.The plan ingitpython-developers#2005 is to start without them, and no OS-specificproblems have been identified so far. In particular, in theprevious commit that adds 3.13t without excluding any operatingsystems, all tests in the macOS job passed as expected, and theWindows job had the same failure with the same message as ingitpython-developers#1955,with no XFAIL changed to XPASS (which, if present, would suggestGC differences meriting further exploration of 3.13t on Windows).
I still hope to complete this properly, but in the meantime I've renamed this PR to reflect that GitPython is already believed to work on Python 3.13 other than on Windows (where it probably works mostly but not entirely), so that users on Unix-like systems are not misled into thinking they can't upgrade. |
I just noticed that |
Uh oh!
There was an error while loading.Please reload this page.
Tasks for full Python 3.13 support (the "Audit all ..." tasks can arguably be deferred if necessary):
imghdr
(#1954)index.remove('/only/looks/absolute')
should do on Windowsos.path.isabs
in GitPythonsetup.py
classifier (though it's not needed for installation)py313
to theenv_list
intox.ini
(can do at any time, if tested out)Python 3.13 has been out for a few months now (and even has a patch release, 3.13.1), but I have not yet gotten to finishing this. I believe GitPython alreadymostly works on Python 3.13, including the recently released current version of GitPython as well as other recent-past versions. But there was a change to the behavior of
os.path.isabs
on Windows in Python 3.13 that affects some functionality. The problem affects only Windows; GitPython should already completely work with Python 3.13 on other operating systems, though of course it is possible that other version-specific bugs are not yet discovered.Unlike on Unix-like systems, most paths on Windows that begin with a directory separator are actually relative paths, because a path that begins with a single
\
or/
--rather than, for example,\\?\
,\\.\
, or\\hostname\
--is relative to the root of thecurrent drive (unless it begins with\??\
and is used in a context where that syntax is accepted). But ordinary drive-relative\
paths are reported as absolute inos.path.isabs
prior to Python 3.13, even thoughpathlib.Path
functions do not misreport them in this way.This rightly causes one test to fail. In addition, this points to a likely area of confusion when handling paths in Windows, and the code covered by the failing test, as well as other code that checks through
os.path
funcitons orpathlib.Path
methods if paths are absolute or relative on Windows should be examined.I believe it is to avoid breaking code that relies on the old behavior that earlier versions of Python have not been updated to fix
os.path.isabs
for these kinds of paths. But any code that relies on that is likely to be doing the wrong thing. More broadly, any code that assume a path is absolute if and only if it begins with a directory separator is likely to be doing the wrong thing on Windows, even if it does not make use of library functions that encapsulate this assumption.The original pull request description follows, including some elaboration related to the tasks.