Drop Python 3.7

[mwtoews]

Unsure if this is good timing or not, but Python 3.7 reached it's EOL in 2023 (PEP 537), so is overdue to be dropped. This helps reduce the maintenance burden and reduces the CI churn, which are good things. It was 5 years ago this project dropped Python 3.6, for reference.

A few old bits of Python 2 are also identified and modernized, like IOError -> OSError and other minor changes.

[Byron]

Thanks a lot, I also think it should be fine to drop support and simplify the code accordingly.

CC @EliahKagan if there is anything speaking against dropping py 3.7, we can undo this change as well (while I hope that won't be necessary.

[EliahKagan]

This seems reasonable; I have no objection to dropping Python 3.7 support at this time. GitPython has traditionally kept support for EoL versions for Python for a long time after they have become EoL, a practice that I think has considerable value for GitPython, but Python 3.7 is extremely old at this point--multiple subsequent releases are EoL now. I suggest going ahead and dropping support for Python 3.7 if there are identifiable benefits, while continuing to support 3.8 and onwards for now.

I'm not sure reducing CI load or churn is a clear enough benefit to justify dropping Python 3.7, but I think there are others. I think there are a number of places in the code where we are writing code cumbersomely due to not having access to language and library features introduced in Python 3.8 (some commented, many not). Some of those seem also to be improved here--though some of the improvements here don't seem to be incompatible with Python 3.7; for example, I think IOError and OSError have been the same type since Python 3.3. [Edit: Now I see that the description here covers that, describing it as being related to modernizing old Python 2 style constructions.]

There is the question of whether this constitutes a breaking change. Because requires-python has changed, anyone still on Python 3.7 (which hopefully is no one) won't get the new packages anyway, so in one of the most important senses it's non-breaking. I do recommend bumping at least the minor version number; while GitPython tends to take a broader view than SemVer about what can come in a new patch (versus minor) version, dropping support for an EoL version of Python seems like something no one would expect to come in a patch version.

Also, I wonder if actually we have breaking changes on the main branch since the most recent release. Specifically, #2243 looks like a breaking change, albeit one that might not actually break anything people are really using: before, one could do pip install 'gitpython[doc]', and I think that is no longer possible since the change in #2243. There's a question of whether that's a valuable thing to do--personally I am somewhat skeptical of the idea that dependency groups are preferable to extras--but I don't think there's any big problem with it, and assuming that change is kept, technically the next release is breaking.

If the next release does get a major version bump, then various other small breaking changes could maybe be done and included in it, but I recommend against rushing in anything big. I think it should be okay for some or all of what is currently planned in #2177 for GitPython 4.0.0 to come in (when it is ready) as GitPython 5.0.0 instead.

If you don't want a major version bump at this time, then dropping Python 3.7 doesn't need to be done in one; a minor version bump is okay. But in that case I recommend looking at #2243 and also examining other changes that have been coming in to see if they are breaking. (I just happened to notice that #2243 might be breaking; I haven't been looking for breaking changes in recent PRs.)

[Byron]

Thanks so much for chiming in!

[..] while GitPython tends to take a broader view than SemVer about what can come in a new patch (versus minor) version, dropping support for an EoL version of Python seems like something no one would expect to come in a patch version.

I made sure the next version is a minor bump, while mentioning the removal of Python 3.7 in the changelog.

Also, I wonder if actually we have breaking changes on the main branch since the most recent release. Specifically, #2243 looks like a breaking change, albeit one that might not actually break anything people are really using: before, one could do pip install 'gitpython[doc]', and I think that is no longer possible since the change in #2243. There's a question of whether that's a valuable thing to do--personally I am somewhat skeptical of the idea that dependency groups are preferable to extras--but I don't think there's any big problem with it, and assuming that change is kept, technically the next release is breaking.

Oh, I wasn't aware at all, probably because I never considered build-system settings to be part of a semver contract.

If you don't want a major version bump at this time, then dropping Python 3.7 doesn't need to be done in one; a minor version bump is okay. But in that case I recommend looking at #2243 and also examining other changes that have been coming in to see if they are breaking. (I just happened to notice that #2243 might be breaking; I haven't been looking for breaking changes in recent PRs.)

Major isn't planned at all, and I don't think there is API breaking changes, which, as I learned recently and the hard way, are very easily overlooked.

So I think it would be good to have your final verdict on #2243, which seems to modernize how doc dependencies are specified. Something I find strange is to not be able to update how this is done, and I would declare it non-breaking, but then again, one word from you and I will revert the commit and put it into the #2177 PR.

Thanks again, and sorry for the hassle.