This is analogous to the 3.7-related CI change in gitdb that waspart ofgitpython-developers/gitdb#114, asto part ofgitpython-developers/smmap#58.Since some tests are not yet passing on 3.13, this does not add3.13 to CI, nor to the documentation of supported versions in`setup.py`. Note that the list there is not enforced; GitPython canalready be installed on Python 3.13 and probably *mostly* works.(Seegitpython-developers#1955for details on other changes that should be made to fully supportrunning 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] <support@github.com>

To try to find the bug that causes it to fail on Cygwin on CI, butnot on other systems on CI, and not locally on Cygwin.It looks like there's an extra line being read from stderr when thetest fails, so let's examine the lines themselves.

The main change here is to the Cygwin test workflow, which now runsthe tests in a venv (a Python virtual environment), to avoid mixingup our intended dependencies with other files installed by Pythonrelated packages on the system. This should either fix the problemwhere `test_handle_process_output` reports an extra line in stderrfor the `cat_file.py` subprocess on CI or Cygwin, or at least makeit somewhat easier to continue investigating the problem. I thinkthis change is also valuable for its own sake.The connection to the `test_handle_process_output` failure is thatthe extra line in stderr appears at the beginning and is an errormessage 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: AssertionErrorThis could possibly be worked around by attempting to install apackage to provide `iniconfig`, by configuring `pytest-cov` in away that does not require it, or by temporarily disabling codecoverage reports on Cygwin. Before exploring those or otheroptions, this change seeks to prepare a more isolated environmentin which different package versions are more likely to workproperly together.In addition to that change to the Cygwin workflow, this alsochanges the way the Alpine Linux test workflow is made to use avenv, using the technique that is used here, and undoing somechanges in the Alpine Linux workflow that should not be necessary.The reason for making that change together with this Cygwin changeis that if either does not work as expected, it might shed light onwhat 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 onCygwin is `BASH_ENV` (since script steps are run in `bash`), whilethe 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 invokedthrough `sudo`).

`busybox sh` does not appear to read commands from a file whosepath is given as the value of `$ENV`, in this situation. I think Imay have misunderstood that; the documentation does not say muchabout it and maybe, in Almquist-style shells, it is only read byinteractive shells? I am not sure.This removes everything about `ENV` and activates the venv in eachstep where the venv should be used.The good news is that the technique did work fully in Cygwin: notonly did `BASH_ENV` work (which was not much in doubt), but usinga virtual environment for all steps that run test code on Cygwinfixed the problem and allowed all tests to pass. That seems to havebeen the reason I didn't reproduce the problem locally: on my localsystem I always use a venv in Cygwin since I would otherwise nothave adequate isolation.Thus, this commit changes only the Alpine workflow and not theCygwin workflow.

Byron left a comment