You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have an application which itself uses pytest. I therefore have two config files for pytest:
An "outer" config file (I use pyproject.toml) which controls tests of the application itself.
An "inner" pytest.ini config file, located in a project subdir that's included in the published package, which controls how pytest runs when executed by the running application.
In that inner pytest.ini, I don't have a setting for asyncio_default_fixture_loop_scope - it should not be needed, since the running application doesn't use the pytest-asyncio plugin.
What I expect
When I run pytest to test the application (i.e., start it from the project root-dir and verify that it reports that it's using pyproject.toml as the config file), I expect no warnings about unset asyncio_default_fixture_loop_scope.
What actually happens
I still get the warning. I see this in console output:
My console output
% pytest
Test session starts (platform: darwin, Python 3.11.10, pytest 8.2.2, pytest-sugar 1.0.0)
benchmark: 4.0.0 (defaults: timer=time.perf_counter disable_gc=False min_rounds=5 min_time=0.000005 max_time=1.0 calibration_precision=10 warmup=False warmup_iterations=100000)
rootdir: /Users/jclerman/git/backend-integration-tester
configfile: pyproject.toml
plugins: ddtrace-2.14.4, cov-5.0.0, sugar-1.0.0, icdiff-0.9, benchmark-4.0.0, anyio-4.6.2.post1, asyncio-0.25.1
asyncio: mode=Mode.STRICT, asyncio_default_fixture_loop_scope=function
... # omitting test-results here
============================================================================================================= warnings summary =============================================================================================================
tests/rest_api/test_routes.py::test_start_test_run[request_payload0-2-2-1-0-1]
tests/rest_api/test_routes.py::test_start_test_run[request_payload1-2-0-0-0-0]
/Users/jclerman/Library/Caches/pypoetry/virtualenvs/backend-integration-tester-V08Hc2cc-py3.11/lib/python3.11/site-packages/pytest_asyncio/plugin.py:207: PytestDeprecationWarning: The configuration option "asyncio_default_fixture_loop_scope" is unset.
The event loop scope for asynchronous fixtures will default to the fixture caching scope. Future versions of pytest-asyncio will default the loop scope for asynchronous fixtures to function scope. Set the default fixture loop scope explicitly in order to avoid unexpected behavior in the future. Valid fixture loop scopes are: "function", "class", "module", "package", "session"
warnings.warn(PytestDeprecationWarning(_DEFAULT_FIXTURE_LOOP_SCOPE_UNSET))
-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html
Workaround
I have verified that adding the option to the inner pytest.ini makes the warning disappear.
The text was updated successfully, but these errors were encountered:
My situation
I have an application which itself uses
pytest
. I therefore have two config files for pytest:pyproject.toml
) which controls tests of the application itself.pytest.ini
config file, located in a project subdir that's included in the published package, which controls howpytest
runs when executed by the running application.In
pyproject.toml
, I've included:In that inner
pytest.ini
, I don't have a setting forasyncio_default_fixture_loop_scope
- it should not be needed, since the running application doesn't use thepytest-asyncio
plugin.What I expect
When I run pytest to test the application (i.e., start it from the project root-dir and verify that it reports that it's using
pyproject.toml
as the config file), I expect no warnings about unsetasyncio_default_fixture_loop_scope
.What actually happens
I still get the warning. I see this in console output:
My console output
Workaround
I have verified that adding the option to the inner
pytest.ini
makes the warning disappear.The text was updated successfully, but these errors were encountered: