GeezerVison is showing github.com — Support Python 3.13 on Windows by EliahKagan · Pull Request #1955 · gitpython-developers/GitPython
Conversation
EliahKagan
commented
Aug 18, 2024
•
edited
Loading
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):
- All platforms: Upgrade Sphinx packages to not use
imghdr (#1954)
- All platforms: In CI
mypy step, fix --python-version operand to omit trailing t (#2040)
- Windows: Figure out what
index.remove('/only/looks/absolute') should do on Windows
- Windows: Audit all other uses of
os.path.isabs in GitPython
- Windows: Audit all choices GitPython makes based on whether paths are absolute or relative
- All platforms: Add Python 3.13
setup.py classifier (though it's not needed for installation)
- All platforms: Add
py313 to the env_list in tox.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 already mostly 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 the current 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 in os.path.isabs prior to Python 3.13, even though pathlib.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 or pathlib.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.
Python 3.13 is currently a release candidate (3.13.0rc1). Initially all this draft PR does is enable it for CI.
This is not ready to merge. There are two failures on CI:
On Windows, a test fails due to the change in 3.13 to os.path.isabs. I hope to fix that here, but I definitely have no objection if someone else wishes to fix it (which can supersede or, if desired, build on whatever ends up here). I'll also try to expand on that and related issues, here or elsewhere. It is not obvious what the best fix is. This is because the confusion that led to the old behavior of os.path.isabs (and the skew between its behavior and that of Path.is_absolute), as well as possibly other conceptually related issues, seem also to affect GitPython, including the code that leads to the current 3.13 test failure.
On all platforms, generating documentation fails (though the CI results don't show it for Windows because the unit test step fails first). This happens because 3.13 removes a number of deprecated modules, and one of them is imghdr, which the old version of Sphinx we've been using attempts to import. This is fixed in #1954, and I plan to rebase this PR if that is merged.
In addition, though possibly not in this PR, because we currently list every version we support in the metadata defined in setup.py, once there is good reason to believe that GitPython works properly on 3.13, it should be added. (This is purely informational, and unrelated to the version range used to determine whether and what versions of GitPython are installable for what versions of Python.)
That could be done either in this PR or subsequent to it, depending on whether the changes here are sufficient to provide that confidence. But I do not take it to be a goal of this PR to do that; once CI is passing without suppressing anything, I think this would be ready. Then we would have CI in place that would help with further changes aimed at improving 3.13 support or fixing 3.13-nonspecific problems discovered while investigating 3.13-specific matters.
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
edgarrmondragon reacted with thumbs up emoji
EliahKagan
added a commit
to EliahKagan/GitPython
that referenced
this pull request
Jan 2, 2025
This is analogous to the 3.7-related CI change in gitdb that was
part of gitpython-developers/gitdb#114, as
to part of gitpython-developers/smmap#58.
Since some tests are not yet passing on 3.13, this does not add
3.13 to CI, nor to the documentation of supported versions in
`setup.py`. Note that the list there is not enforced; GitPython can
already be installed on Python 3.13 and probably *mostly* works.
(See gitpython-developers#1955
for details on other changes that should be made to fully support
running GitPython on Python 3.13.)
EliahKagan
added a commit
to EliahKagan/GitPython
that referenced
this pull request
Jan 2, 2025
Since gitpython-developers#1987, test jobs from `pythonpackage.yml` appear in an
unintuitive order, and some show an extra bool matrix variable in
their 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 without
setting `continue-on-error` to temporarily work around the problems
obseved in gitpython-developers#1955, but nothing 3.13-related is done in this commit.
EliahKagan
added a commit
to EliahKagan/GitPython
that referenced
this pull request
Jan 2, 2025
As this is being integrated, Python 3.13 is no longer a release
candidate, but this marks it experimental since that might also be
used temporarily to prevent some of the failures mentioned in gitpython-developers#1955
from failing the workflow.
But right now this allows the workflow to fail.
EliahKagan
added a commit
to EliahKagan/GitPython
that referenced
this pull request
Jan 2, 2025
Since gitpython-developers#1987, test jobs from `pythonpackage.yml` appear in an
unintuitive order, and some show an extra bool matrix variable in
their 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 without
setting `continue-on-error` to temporarily work around the problems
obseved in gitpython-developers#1955, but nothing 3.13-related is done in this commit.
EliahKagan
added a commit
to EliahKagan/GitPython
that referenced
this pull request
Jan 2, 2025
As this is being integrated, Python 3.13 is no longer a release
candidate, but this marks it experimental since that might also be
used temporarily to prevent some of the failures mentioned in gitpython-developers#1955
from failing the workflow.
But right now this allows the workflow to fail.
EliahKagan
added a commit
to EliahKagan/GitPython
that referenced
this pull request
Jan 2, 2025
It is specifically that combination that breaks some things. The
underlying cause is a change in `isabs` to correctly report that
paths on Windows that start with `\` that is not part of a
construction such as `\\?\` are not absolute paths. (See gitpython-developers#1955 and
links therein.) The change to `isabs` starts in 3.13, and it is
only applicable to Windows, so only that combination is affected.
This was referenced Jan 2, 2025
EliahKagan
added a commit
to EliahKagan/GitPython
that referenced
this pull request
Jan 4, 2025
Since gitpython-developers#1987, test jobs from `pythonpackage.yml` appear in an
unintuitive order, and some show an extra bool matrix variable in
their 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 without
setting `continue-on-error` to temporarily work around the problems
obseved in gitpython-developers#1955, but nothing 3.13-related is done in this commit.
EliahKagan
added a commit
to EliahKagan/GitPython
that referenced
this pull request
Jan 4, 2025
As this is being integrated, Python 3.13 is no longer a release
candidate, but this marks it experimental since that might also be
used temporarily to prevent some of the failures mentioned in gitpython-developers#1955
from failing the workflow.
But right now this allows the workflow to fail.
EliahKagan
added a commit
to EliahKagan/GitPython
that referenced
this pull request
Jan 4, 2025
It is specifically that combination that breaks some things. The
underlying cause is a change in `isabs` to correctly report that
paths on Windows that start with `\` that is not part of a
construction such as `\\?\` are not absolute paths. (See gitpython-developers#1955 and
links therein.) The change to `isabs` starts in 3.13, and it is
only applicable to Windows, so only that combination is affected.
This was referenced Feb 16, 2025
EliahKagan
added a commit
to EliahKagan/GitPython
that referenced
this pull request
Mar 7, 2025
As this is being integrated, Python 3.13 is no longer a release
candidate, but this marks it experimental since that might also be
used temporarily to prevent some of the failures mentioned in gitpython-developers#1955
from failing the workflow.
But right now this allows the workflow to fail.
EliahKagan
added a commit
to EliahKagan/GitPython
that referenced
this pull request
Mar 7, 2025
It is specifically that combination that breaks some things. The
underlying cause is a change in `isabs` to correctly report that
paths on Windows that start with `\` that is not part of a
construction such as `\\?\` are not absolute paths. (See gitpython-developers#1955 and
links therein.) The change to `isabs` starts in 3.13, and it is
only applicable to Windows, so only that combination is affected.
As this is being integrated, Python 3.13 is no longer a release
candidate, but this marks it experimental since that might also be
used temporarily to prevent some of the failures mentioned in gitpython-developers#1955
from failing the workflow.
But right now this allows the workflow to fail.
It is specifically that combination that breaks some things. The
underlying cause is a change in `isabs` to correctly report that
paths on Windows that start with `\` that is not part of a
construction such as `\\?\` are not absolute paths. (See gitpython-developers#1955 and
links therein.) The change to `isabs` starts in 3.13, and it is
only 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 block
indefinitely waiting on a self-hosted runner with `windows-` as a
label). I don't know why this happens, since it looks like it did
not happen before rebasing from 65ff35f to 6060afd, but it happens
when force-pushing back to that OID from before the rebase. This
usually indicates a change in the runner software (or some other
part of the GHA infrastructure), but it could be that it happened
before and went unnoticed (then looked like a failure but was
actually a cancellation?).
EliahKagan
added a commit
to EliahKagan/GitPython
that referenced
this pull request
Mar 7, 2025
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 7, 2025
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).
Byron
pushed a commit
to EliahKagan/GitPython
that referenced
this pull request
Mar 12, 2025
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).
|
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.
|
Byron reacted with thumbs up emoji
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
|
I just noticed that tox.ini has also not been updated for Python 3.13. That could possibly be done sooner than other changes here, but for now I've added it to the task list here.
|
Byron reacted with thumbs up emoji
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
|
While I cleanup, please allow me to ask you to recreate this PR once you have time to work on it, or to try things in your fork. Thanks for your understanding🙏.
|
EliahKagan reacted with thumbs up emoji
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
|
Thanks--and sorry about leaving this in this state for to long.
|
Sorry, something went wrong.
Uh oh!
There was an error while loading. Please reload this page.
Byron
pushed a commit
that referenced
this pull request
Jul 28, 2026
This commit also makes the test-suite independent of the presence of a
local `master` branch.
- make index and submodule path normalization distinguish drive-rooted, drive-relative, UNC, and device paths on Windows
- confine normalized paths with `commonpath` instead of string-prefix checks
- normalize `includeIf gitdir` patterns to Git-style separators
- cover the other `isabs` consumers whose drive-rooted behavior correctly relies on Windows join semantics
- remove the Windows 3.13-3.15 CI exclusions and add 3.13-3.15 to tox
- make the pre-existing tests independent of a local `master` branch and linked-worktree-specific alternates
For context, the classifiers mentioned in the issue #2072 were introduced by 904aa71
(`Declare support for Python 3.13-3.14`) and 7d5370d (`Add support for Python
3.15`), both included in 3.1.56. This PR supplies the Windows path work that
those metadata changes did not include.
- paths absolute on the current drive
- drive-rooted paths such as `\directory` and `/directory`
- drive-relative paths such as `C:directory` (rejected where repository confinement is required)
- other-drive, UNC, and device paths
- traversal and adjacent-prefix escape attempts
- native and Git-style separators in conditional includes
- config includes, submodule gitfiles, linked worktree metadata, clone destinations, and Cygwin-path conversion
- Python 3.12.13, 3.13.14, 3.14.6, 3.14.6t, 3.15.0b4, and 3.15.0b4t installed locally with uv
- full test set passed for every interpreter in an independent clone without a
local `master` branch; daemon-free suites ran in parallel and `test_remote.py`
ran serially because its static local daemon endpoint cannot be shared across
processes
- Ruff check and format
- mypy
- basedpyright
- all pre-commit hooks
Byron
added a commit
that referenced
this pull request
Jul 28, 2026
This commit also makes the test-suite independent of the presence of a
local `master` branch.
<!-- agent -->
- make index and submodule path normalization distinguish drive-rooted, drive-relative, UNC, and device paths on Windows
- confine normalized paths with `commonpath` instead of string-prefix checks
- normalize `includeIf gitdir` patterns to Git-style separators
- cover the other `isabs` consumers whose drive-rooted behavior correctly relies on Windows join semantics
- remove the Windows 3.13-3.15 CI exclusions and add 3.13-3.15 to tox
- make the pre-existing tests independent of a local `master` branch and linked-worktree-specific alternates
For context, the classifiers mentioned in the issue #2072 were introduced by 904aa71
(`Declare support for Python 3.13-3.14`) and 7d5370d (`Add support for Python
3.15`), both included in 3.1.56. This PR supplies the Windows path work that
those metadata changes did not include.
- paths absolute on the current drive
- drive-rooted paths such as `\directory` and `/directory`
- drive-relative paths such as `C:directory` (rejected where repository confinement is required)
- other-drive, UNC, and device paths
- traversal and adjacent-prefix escape attempts
- native and Git-style separators in conditional includes
- config includes, submodule gitfiles, linked worktree metadata, clone destinations, and Cygwin-path conversion
- Python 3.12.13, 3.13.14, 3.14.6, 3.14.6t, 3.15.0b4, and 3.15.0b4t installed locally with uv
- full test set passed for every interpreter in an independent clone without a
local `master` branch; daemon-free suites ran in parallel and `test_remote.py`
ran serially because its static local daemon endpoint cannot be shared across
processes
- Ruff check and format
- mypy
- basedpyright
- all pre-commit hooks
Assisted-by: GPT 5.6
Co-authored-by: GPT 5.6 <[email protected]>
Byron
added a commit
that referenced
this pull request
Aug 4, 2026
This commit also makes the test-suite independent of the presence of a
local `master` branch.
<!-- agent -->
- make index and submodule path normalization distinguish drive-rooted, drive-relative, UNC, and device paths on Windows
- confine normalized paths with `commonpath` instead of string-prefix checks
- normalize `includeIf gitdir` patterns to Git-style separators
- cover the other `isabs` consumers whose drive-rooted behavior correctly relies on Windows join semantics
- remove the Windows 3.13-3.15 CI exclusions and add 3.13-3.15 to tox
- make the pre-existing tests independent of a local `master` branch and linked-worktree-specific alternates
For context, the classifiers mentioned in the issue #2072 were introduced by 904aa71
(`Declare support for Python 3.13-3.14`) and 7d5370d (`Add support for Python
3.15`), both included in 3.1.56. This PR supplies the Windows path work that
those metadata changes did not include.
- paths absolute on the current drive
- drive-rooted paths such as `\directory` and `/directory`
- drive-relative paths such as `C:directory` (rejected where repository confinement is required)
- other-drive, UNC, and device paths
- traversal and adjacent-prefix escape attempts
- native and Git-style separators in conditional includes
- config includes, submodule gitfiles, linked worktree metadata, clone destinations, and Cygwin-path conversion
- Python 3.12.13, 3.13.14, 3.14.6, 3.14.6t, 3.15.0b4, and 3.15.0b4t installed locally with uv
- full test set passed for every interpreter in an independent clone without a
local `master` branch; daemon-free suites ran in parallel and `test_remote.py`
ran serially because its static local daemon endpoint cannot be shared across
processes
- Ruff check and format
- mypy
- basedpyright
- all pre-commit hooks
Assisted-by: GPT 5.6
Co-authored-by: GPT 5.6 <[email protected]>
Byron
added a commit
that referenced
this pull request
Aug 4, 2026
This commit also makes the test-suite independent of the presence of a
local `master` branch.
<!-- agent -->
- make index and submodule path normalization distinguish drive-rooted, drive-relative, UNC, and device paths on Windows
- confine normalized paths with `commonpath` instead of string-prefix checks
- normalize `includeIf gitdir` patterns to Git-style separators
- cover the other `isabs` consumers whose drive-rooted behavior correctly relies on Windows join semantics
- remove the Windows 3.13-3.15 CI exclusions and add 3.13-3.15 to tox
- make the pre-existing tests independent of a local `master` branch and linked-worktree-specific alternates
For context, the classifiers mentioned in the issue #2072 were introduced by 904aa71
(`Declare support for Python 3.13-3.14`) and 7d5370d (`Add support for Python
3.15`), both included in 3.1.56. This PR supplies the Windows path work that
those metadata changes did not include.
- paths absolute on the current drive
- drive-rooted paths such as `\directory` and `/directory`
- drive-relative paths such as `C:directory` (rejected where repository confinement is required)
- other-drive, UNC, and device paths
- traversal and adjacent-prefix escape attempts
- native and Git-style separators in conditional includes
- config includes, submodule gitfiles, linked worktree metadata, clone destinations, and Cygwin-path conversion
- Python 3.12.13, 3.13.14, 3.14.6, 3.14.6t, 3.15.0b4, and 3.15.0b4t installed locally with uv
- full test set passed for every interpreter in an independent clone without a
local `master` branch; daemon-free suites ran in parallel and `test_remote.py`
ran serially because its static local daemon endpoint cannot be shared across
processes
- Ruff check and format
- mypy
- basedpyright
- all pre-commit hooks
Assisted-by: GPT 5.6
Co-authored-by: GPT 5.6 <[email protected]>
Reviewers
Copilot will automatically review once the pull request is marked ready for review
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.
|