Skip to content

Plugins modifying output can break pytester #13369

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

Open
1 of 4 tasks
hseg opened this issue Apr 10, 2025 · 2 comments
Open
1 of 4 tasks

Plugins modifying output can break pytester #13369

hseg opened this issue Apr 10, 2025 · 2 comments
Labels
type: docs documentation improvement, missing or needing clarification

Comments

@hseg
Copy link

hseg commented Apr 10, 2025

When executing pytester.runpytest in an environment containing a pytest plugin that modifies the output, the result is that vanilla pytester tries and fails to parse the modified output, yielding failed assert_outcomes.

For example, the following test suite, in an environment with pytest-pretty installed:

import pytest

@pytest.mark.parametrize('params', [[], ['-p pretty'], ['-p no:pretty']])
def test_rec(testdir, params):
    testdir.makepyfile(
    """
    import pytest
    def test_noop():
        assert True is True
    """
    )
    result = testdir.runpytest(*params)
    result.assert_outcomes(passed=1)

if __name__ == '__main__':
    print('default')
    pytest.main(plugins=['pytester'])
    print('-p pretty')
    pytest.main(plugins=['pytester', 'pretty'])
    print('-p no:pretty')
    pytest.main(['-p', 'no:pretty'], plugins=['pytester'])

succeeds only when the internal testsuite is passed -p no:pretty, regardless of the flags with which pytest.main is invoked

This is an issue in certain contexts, eg kiwicom/pytest-recording#169 In that case, packaging guidelines for Arch Linux mandate running the builders without venvs. And while guidelines there mandate building packages in a chroot with only the dependencies the package needs, it is common for users to build packages outside such a chroot, and so they pick up such plugins.

One additional factor here is that diagnosing this incompatibility is difficult -- none of the plugins involved advertise this incompatibility, and the code itself doesn't suggest anything might be wrong.

Several mitigations suggest themselves, in increasing order of complexity and safety:

  • Explicitly specifying the plugins to use -- this is what Gentoo does, and I'm currently writing up a proposal have proposed that Arch should do the same. This was enabled by Option to disable plugin autoload entirely #3784
  • Document prominently in the pytester documentation that it is incompatible with any plugin that modifies pytest's output
  • Standardize an interface for overriding the output to ensure that any fixture that calls runpytest will have a coherent set of bindings. eg enable explicitly setting which reporter pytest uses for its reporting, and then have runpytest explicitly but overridably set the reporter (so it's always parsing the report with the reporter it was expecting to be using)
  • Give pytest a way to emit a machine-readable version of the log, so it's not dependent on its output not being modified (eg have a flag for machine-readable output, and use that with runpytest under the hood)

pytest version: 8.3.5

@Zac-HD Zac-HD added the type: docs documentation improvement, missing or needing clarification label Apr 12, 2025
@Zac-HD
Copy link
Member

Zac-HD commented Apr 12, 2025

I think we could both document this issue, and ensure that pytester raises a better error message if it fails to parse output.

@RonnyPfannschmidt
Copy link
Member

We should probably work towards explicitly managing autoload for pytester

archlinux-github pushed a commit to archlinux/aur that referenced this issue May 18, 2025
By enumerating the pytest plugins we actually use, we avoid such cases
as pytest-dev/pytest#13369
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: docs documentation improvement, missing or needing clarification
Projects
None yet
Development

No branches or pull requests

3 participants