Use upgraded pip in test fixture virtual environment

[EliahKagan]

A couple of GitPython's tests create their own virtual environments. One of those tests, test_installation, uses pip in it. But it does not upgrade pip in that virtual environment before using it, so an old version is often used. (The virtual environment is deliberately isolated, so pip being current in the environment used to run the tests is not sufficient.)

This creates a problem with pip on Cygwin. pip vendors pytoml to read pyproject.toml files. But the version of pytoml vendored by some old versions of pip--including the one currently used in a virtual environment in which pip has not been upgraded--is apparently unable to parse some syntactically correct TOML, at least on some platforms. This was undetected because the contents of pyproject.toml on the main branch do not trigger the bug.

This is the cause of the Cygwin test failure in #1862 (at a083e81). The failing test is test_installation; the detailed information on the failure begins here in the log. The key is these lines from the error message:

pip._vendor.pytoml.core.TomlError: /tmp/pip-req-build-yjylhtt5/pyproject.toml(61, 1): msg
WARNING: You are using pip version 19.2.3, however version 24.0 is available.

Often, such warnings are unrelated to errors that precede them, but in this case the low version of pip really is the cause. Changing the VirtualEnvironment test fixture to upgrade pip when it creates a virtual environment where pip is going to be used is sufficient to fix the problem.

This pull request makes that change. It also upgrades setuptools when the Python version is lower than 3.12, which is recommended to do. From Python 3.9 on, venv.create has an upgrade_deps parameter that would make all of this very straightforward...except that using that would make test_installation incompatible with Python 3.7 and Python 3.8 (including on systems other than Cygwin). So I ended up doing it manually instead.

---

This pull request has the main branch in the upstream GitPython repository as its base, but I have also tested these changes on top of #1862 (as it stands currently, with a083e81 at its tip) and verified that they fix the problem reported there and allow all CI checks to pass, including the Cygwin test workflow and the linting workflow with Ruff.

I'm not sure what the best way is to integrate the changes here and in #1862. This could be merged to main, and then #1862 could be updated. Or this could be merged, and #1862 merged without updating it, trusting that the checks would go green on the main branch. Or the changes here could be replayed there (e.g., by fast-forwarding it to my ruff-pip-toml branch), or that could be merged first with the failing check and then this could be merged, etc. (I have no objection if these changes are integrated in a way results in this pull request itself being closed without merging.)

[Byron]

Thanks so much for helping with this!

The line that indicates the culprit is something I once again missed. It looks like I really can't investigate test-failures anymore, while also admitting that I only scroll all the way down to see the one-line summary of the failure. Searching for the test-case should help, next time.

Supporting this many python versions and platforms isn't easy, and I am impressed by your ability to dig through all that anyway.

[EliahKagan]

Until an improvement is made related to the xfail distraction issue discussed at #1853 (comment) and #1853 (comment), a technique I've found useful--in addition to searching for the test-case name as you mention--is to scan upward for when the percentages shown at the ends of most lines change color from yellow/gold to red. This always marks the the first test with "FAIL" status in the test run.