GeezerVison

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.)

Bumps [Vampire/setup-wsl](https://github.com/vampire/setup-wsl) from 3.1.1 to 4.0.0.
- [Release notes](https://github.com/vampire/setup-wsl/releases)
- [Commits](Vampire/setup-wsl@v3.1.1...v4.0.0)

---
updated-dependencies:
- dependency-name: Vampire/setup-wsl
  dependency-type: direct:production
  update-type: version-update:semver-major
...

Signed-off-by: dependabot[bot] <[email protected]>

To try to find the bug that causes it to fail on Cygwin on CI, but
not on other systems on CI, and not locally on Cygwin.

It looks like there's an extra line being read from stderr when the
test fails, so let's examine the lines themselves.

The main change here is to the Cygwin test workflow, which now runs
the tests in a venv (a Python virtual environment), to avoid mixing
up our intended dependencies with other files installed by Python
related packages on the system. This should either fix the problem
where `test_handle_process_output` reports an extra line in stderr
for the `cat_file.py` subprocess on CI or Cygwin, or at least make
it somewhat easier to continue investigating the problem. I think
this change is also valuable for its own sake.

The connection to the `test_handle_process_output` failure is that
the extra line in stderr appears at the beginning and is an error
message about a missing import needed for subprocess code coverage.
With the recently added more detailed error reporting, it shows:

            self.assertEqual(line_counts[1], expected_line_count, repr(lines[1]))
    >       self.assertEqual(line_counts[2], expected_line_count, repr(lines[2]))
    E       AssertionError: 5003 != 5002 : ['pytest-cov: Failed to setup subprocess coverage. Environ: {\'COV_CORE_SOURCE\': \'git\', \'COV_CORE_CONFIG\': \':\', \'COV_CORE_DATAFILE\': \'/cygdrive/d/a/GitPython/GitPython/.coverage\'} Exception: ModuleNotFoundError("No module named \'iniconfig\'")\n', 'From github.com:jantman/gitpython_issue_301\n', ' = [up to date]      master     -> origin/master\n', ' = [up to date]      testcommit1 -> origin/testcommit1\n', ' = [up to date]      testcommit10 -> origin/testcommit10\n', ' = [up to date]      testcommit100 -> origin/testcommit100\n', ' = [up to date]      testcommit1000 -> origin/testcommit1000\n', ' = [up to date]      testcommit1001 -> origin/testcommit1001\n', ' = [up to date]      testcommit1002 -> origin/testcommit1002\n', ' = [up to date]      testcommit1003 -> origin/testcommit1003\n', ' = [up to date]      testcommit1004 -> origin/testcommit1004\n', ' = [up to date]      testcommit1005 -> origin/testcommit1005\n', ' = [up to date]      testcommit
    test/test_git.py:793: AssertionError

This could possibly be worked around by attempting to install a
package to provide `iniconfig`, by configuring `pytest-cov` in a
way that does not require it, or by temporarily disabling code
coverage reports on Cygwin. Before exploring those or other
options, this change seeks to prepare a more isolated environment
in which different package versions are more likely to work
properly together.

In addition to that change to the Cygwin workflow, this also
changes the way the Alpine Linux test workflow is made to use a
venv, using the technique that is used here, and undoing some
changes in the Alpine Linux workflow that should not be necessary.
The reason for making that change together with this Cygwin change
is that if either does not work as expected, it might shed light on
what is going wrong with the other.

Although the same technique is used on Cygwin and in Alpine Linux,
it looks a little different, because the environment variable on
Cygwin is `BASH_ENV` (since script steps are run in `bash`), while
the environment variable is `ENV` (since script steps are run in
`busybox sh`) and this must also be allowed to pass through `sudo`
(since `sh`, which is `busybox sh` on this system, is being invoked
through `sudo`).

`busybox sh` does not appear to read commands from a file whose
path is given as the value of `$ENV`, in this situation. I think I
may have misunderstood that; the documentation does not say much
about it and maybe, in Almquist-style shells, it is only read by
interactive shells? I am not sure.

This removes everything about `ENV` and activates the venv in each
step where the venv should be used.

The good news is that the technique did work fully in Cygwin: not
only did `BASH_ENV` work (which was not much in doubt), but using
a virtual environment for all steps that run test code on Cygwin
fixed the problem and allowed all tests to pass. That seems to have
been the reason I didn't reproduce the problem locally: on my local
system I always use a venv in Cygwin since I would otherwise not
have adequate isolation.

Thus, this commit changes only the Alpine workflow and not the
Cygwin workflow.

Byron left a comment