Re: [PATCH 0/6] Transition git-p4.py to support Python 3 only

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Dec 10, 2021, 00:48 UTC
Message-ID: <211210.86r1ale0o0.gmgdl@evledraar.gmail.com>
In-Reply-To: <20211209201029.136886-1-jholdsworth@nvidia.com>

On Thu, Dec 09 2021, Joel Holdsworth wrote:

Show 6 quoted lines

> Python 2 was discontinued in 2020, and there is no longer any officially
> supported interpreter. Further development of git-p4.py will require
> would-be developers to test their changes with all supported dialects of
> the language. However, if there is no longer any supported runtime
> environment available, this places an unreasonable burden on the Git
> project to maintain support for an obselete dialect of the language.

Does it? I can still install Python 2.7 on Debian, presumably other OS's have similar ways to easily test it.

I'm not that familiar with our python integration and have never used git-py, but I found this series hard to read through.

You've got [12]/6 which don't make it clear whether they're needed for python3, or are some mixture of requirenments and a matter of taste (or a newer API?). E.g. isn't the formatting you're changing in 2/6 supported in Python3?

Then for 1/6 "pass cmd arguments to subprocess as a python lists" if it's not just a matter of taste can we lead with a narrow change to the new API (presumably we can pass to our own function as a string, split on whitespace, and then pass to whatever python API executes it as a list first.

Some of these changes also just seem to be entirely unrelated refactorings, e.g. 6/6 where you're changing a multi-line commented regexp into something that's a dense one-liner. Does Python 3 not support the equivalent of Perl's /x, or is something else going on here?

You then change the requirenment not to python 3.0, but 3.7, which AFAICT was released a couple of years ago. We tend to try to capture some of the oldest LTS OS's in common use, e.g. the last 2-3 RHEL releases.

We still "support" Perl 5.8, which was released in 2002 (although that could probably do with a version bump, but not to a release to 2018).

I'm not at all opposed to this Python version bump, I truly don't know enough to know if it's a good change. Maybe we can/should also be more aggressive with a version dependency with git-p4 than with something more central to git like perl or curl.

The commit messages could just really use some extra hand-holding and explanation, and a clear split-out of things related to the version bump v.s. things not needed for that, or unrelated refactorings.