pytest-dev/pytest-asyncio

23 tests fail: TypeError: fixture() got an unexpected keyword argument 'loop_scope'

Opened this issue · 3 comments

log

Version: 1.1.0
Python-3.11
FreeBSD 14.3

Thanks for the log. I think I understand what's happening here.

The main pytest call shows that pytest-asyncio-1.1.0 is used:

plugins: asyncio-1.1.0, anyio-4.9.0, aspectlib-2.0.0, xdist-3.6.1, time-machine-2.13.0, typeguard-4.4.4, mpl-0.17.0, cov-5.0.0, hypothesis-6.136.6

However, some of the tests seem to use an older version of pytest-asyncio (v0.23.8):

running: /usr/local/bin/python3.11 -mpytest --basetemp=/tmp/pytest-of-yuri/pytest-38/test_standalone_test_does_not_trigger_warning_about_no_current_event_loop_being_set0/runpytest-0 --asyncio-mode=strict
in: /tmp/pytest-of-yuri/pytest-38/test_standalone_test_does_not_trigger_warning_about_no_current_event_loop_being_set0
============================= test session starts ==============================
platform freebsd14 -- Python 3.11.13, pytest-8.1.1, pluggy-1.6.0
Matplotlib: 3.8.0
Freetype: 2.13.3
rootdir: /tmp/pytest-of-yuri/pytest-38/test_standalone_test_does_not_trigger_warning_about_no_current_event_loop_being_set0
configfile: tox.ini
plugins: anyio-4.9.0, aspectlib-2.0.0, xdist-3.6.1, time-machine-2.13.0, asyncio-0.23.8, typeguard-4.4.4, mpl-0.17.0, cov-5.0.0, hypothesis-6.136.6
asyncio: mode=Mode.STRICT
collected 1 item

It seems that all affected tests are started in a subprocess using Pytester.runpytest_subprocess. I assume that the subprocesses use the system's installation of pytest-asyncio. This would explain why the pytest-asyncio version changes in the middle of the test suite.

However, I don't know why this is the case. It could be an issue with your specific setup or, if subprocess spawning works differently on FreeBSD vs Linux, it could be an issue in pytest.

From the pytest-asyncio side, I think we can get rid of the calls to Pytester.runpytest_subprocess in favor of running the tests in-process. That only addresses the symptom, though, not the cause.

@yurivict Does this information give you something to go about? Any additional thoughts?

@yurivict Any update on this issue?

Hi guys, I've tested a few different versions and, yes, as @seifertm mentioned, it's related to the version running inrunpytest_subprocess. I can create a quick PR replacing it with runpytest so we can close it, ok?