This fixes a new TestGit::test_handle_process_output test failure on Cygwin where a CoverageWarning was printed to stderr in the Python interpreter subprocess running the cat_file.py fixture.
Background
We usually run the test suite with pytest-cov enabled. This is configured in pyproject.toml to happen by default. pytest-cov uses the coverage module, but it adds some more functionality. This includes instrumenting subprocesses, which is achieved by installing its pytest-cov.pth file into site-packages to be run by all Python interpreter instances. This causes interpeters to check for environment variables such as COV_CORE_SOURCE and to conditionally initialize pytest_cov. For details, see: https://pytest-cov.readthedocs.io/en/latest/subprocess-support.html
coverage 7.9.0 was recently released. One of the changes is to start issuing a warning if it can't import the C tracer core. See: https://github.com/nedbat/coveragepy/releases/tag/7.9.0
Interaction with cat_file.py
If this warning is issued in the cat_file.py subprocess used in test_handle_process_output, it causes the test to fail, because the subprocess writes two more lines to its standard error stream, which cause the line count to come out as two more than expected:
/cygdrive/d/a/GitPython/GitPython/.venv/lib/python3.9/site-packages/coverage/core.py:96: CoverageWarning: Couldn't import C tracer: No module named 'coverage.tracer' (no-ctracer)
warn(f"Couldn't import C tracer: {IMPORT_ERROR}", slug="no-ctracer", once=True)
The Cygwin failure
On most platforms, there is no failure, because the condition the warnings describe does not occur, so there are no warnings. But on Cygwin it does occur, resulting in a new test failure, showing
> self.assertEqual(len(actual_lines[2]), expected_line_count, repr(actual_lines[2]))
E AssertionError: 5004 != 5002 : ["/cygdrive/d/a/GitPython/GitPython/.venv/lib/python3.9/site-packages/coverage/core.py:96: CoverageWarning: Couldn't import C tracer: No module named 'coverage.tracer' (no-ctracer)\n", ' warn(f"Couldn\'t import C tracer: {IMPORT_ERROR}", slug="no-ctracer", once=True)\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', ...
where the first two elements of the list are from the lines of the warning message, and the others are as expected. (The above is a highly abridged extract, with the ... at the end standing for many more list items obtained through the cat_file.py fixture.)
This new failure is triggered specifically by the new coverage package version. It is not due to any recent changes in GitPython. It can be observed by rerunning CI checks that have previously passed, or in:
https://github.com/EliahKagan/GitPython/actions/runs/15598239952/job/43940156308#step:14:355
The fix
There is more than one possible way to fix this, including fixing the underlying condition being warned about on Cygwin, or sanitizing environment variables for the subprocess.
The approach taken here instead is based on the idea that the cat_file.py fixture is very simple, and that it is conceptually just a standalone Python script that doesn't do anything meant to depend on the current Python environment.
Accordingly, this passes the -S option to the interpreter for the cat_file.py subprocess, so that interpreter refrains from loading the site module. This includes, among other simplifying effects, that the subprocess performs no .pth customizations.