Skip to content

Run cat_file.py fixture without site customizations #2052

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Jun 12, 2025

Conversation

EliahKagan
Copy link
Member

@EliahKagan EliahKagan commented Jun 12, 2025

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.

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.

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

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)

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

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.
@EliahKagan EliahKagan marked this pull request as ready for review June 12, 2025 07:46
@EliahKagan EliahKagan merged commit d885bea into gitpython-developers:main Jun 12, 2025
27 checks passed
@EliahKagan EliahKagan deleted the cat-file-nocov branch June 12, 2025 07:46
EliahKagan added a commit to EliahKagan/pytest-cov-test that referenced this pull request Jun 12, 2025
This adds a second test case that passes `-S`, avoiding the
warnings.

(See gitpython-developers/GitPython#2052.)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

1 participant