Allow 'unknown config key' warnings to be filtered out #7649
Conversation
nicoddemus
added
the
needs backport
Why is this the correct time? |
Is just better than was before, at configure time, because at that time the |
|
Regarding Regarding First, are we even sure we want such warnings to appear only in the summary view? It seems perhaps more natural to show at the start already, and keep the summary warnings for collection/test warnings. But actually we seem to have precedence for putting all warnings there, so I guess the answer to this is "yes". Second, the code used Looks like what it needs is to harmonize the diff --git a/src/_pytest/warnings.py b/src/_pytest/warnings.py
index 0604aa60b..79cf547e7 100644
--- a/src/_pytest/warnings.py
+++ b/src/_pytest/warnings.py
@@ -191,7 +191,9 @@ def pytest_sessionfinish(session: Session) -> Generator[None, None, None]:
yield
-def _issue_warning_captured(warning: Warning, hook, stacklevel: int) -> None:
+def _issue_warning_captured(
+ config: Config, warning: Warning, hook, stacklevel: int
+) -> None:
"""A function that should be used instead of calling ``warnings.warn``
directly when we are in the "configure" stage.
@@ -205,6 +207,16 @@ def _issue_warning_captured(warning: Warning, hook, stacklevel: int) -> None:
"""
with warnings.catch_warnings(record=True) as records:
warnings.simplefilter("always", type(warning))
+
+ # Make -W/filterwarnings apply to these warnings as well.
+ # This code is the same as in catch_warnings_for_item().
+ cmdline_filters = config.getoption("pythonwarnings") or []
+ inifilters = config.getini("filterwarnings")
+ for arg in inifilters:
+ warnings.filterwarnings(*_parse_filter(arg, escape=False))
+ for arg in cmdline_filters:
+ warnings.filterwarnings(*_parse_filter(arg, escape=True))
+
warnings.warn(warning, stacklevel=stacklevel)
frame = sys._getframe(stacklevel - 1)
location = frame.f_code.co_filename, frame.f_lineno, frame.f_code.co_nameThis is untested and all of the |
Yep, I realized that right after writing the description, so I decided to keep the commits separate to be able to pluck them out. I agree, will do it. 👍
Oh you are definitely correct in your reasoning! The solution you propose is on point, however I'm not sure it will work (see #2891 (comment)). However that was a long time ago, and deserves to be reviewed if that's still the case. (Also noticed this might be related to fixing #6681). I will give this another spin, thanks a lot @bluetech! |
Warnings are a central part of Python, so much that Python itself has command-line and environtment variables to handle warnings. By moving the concept of warning handling into Config, it becomes natural to filter warnings issued as early as possible, even before the "_pytest.warnings" plugin is given a chance to spring into action. This also avoids the weird coupling between config and the warnings plugin that was required before. Fix pytest-dev#6681 Fix pytest-dev#2891 Fix pytest-dev#7620 Fix pytest-dev#7626 Close pytest-dev#7649
Warnings are a central part of Python, so much that Python itself has command-line and environtment variables to handle warnings. By moving the concept of warning handling into Config, it becomes natural to filter warnings issued as early as possible, even before the "_pytest.warnings" plugin is given a chance to spring into action. This also avoids the weird coupling between config and the warnings plugin that was required before. Fix pytest-dev#6681 Fix pytest-dev#2891 Fix pytest-dev#7620 Fix pytest-dev#7626 Close pytest-dev#7649
Warnings are a central part of Python, so much that Python itself has command-line and environtment variables to handle warnings. By moving the concept of warning handling into Config, it becomes natural to filter warnings issued as early as possible, even before the "_pytest.warnings" plugin is given a chance to spring into action. This also avoids the weird coupling between config and the warnings plugin that was required before. Fix pytest-dev#6681 Fix pytest-dev#2891 Fix pytest-dev#7620 Fix pytest-dev#7626 Close pytest-dev#7649
Warnings are a central part of Python, so much that Python itself has command-line and environtment variables to handle warnings. By moving the concept of warning handling into Config, it becomes natural to filter warnings issued as early as possible, even before the "_pytest.warnings" plugin is given a chance to spring into action. This also avoids the weird coupling between config and the warnings plugin that was required before. Fix pytest-dev#6681 Fix pytest-dev#2891 Fix pytest-dev#7620 Fix pytest-dev#7626 Close pytest-dev#7649
|
Superseded by #7700 |
Warnings are a central part of Python, so much that Python itself has command-line and environtment variables to handle warnings. By moving the concept of warning handling into Config, it becomes natural to filter warnings issued as early as possible, even before the "_pytest.warnings" plugin is given a chance to spring into action. This also avoids the weird coupling between config and the warnings plugin that was required before. Fix pytest-dev#6681 Fix pytest-dev#2891 Fix pytest-dev#7620 Fix pytest-dev#7626 Close pytest-dev#7649
Warnings are a central part of Python, so much that Python itself has command-line and environtment variables to handle warnings. By moving the concept of warning handling into Config, it becomes natural to filter warnings issued as early as possible, even before the "_pytest.warnings" plugin is given a chance to spring into action. This also avoids the weird coupling between config and the warnings plugin that was required before. Fix #6681 Fix #2891 Fix #7620 Fix #7626 Close #7649 Co-authored-by: Ran Benita <[email protected]>
Delay issuing unknown config key warnings until collection is done, which allows users to filter it out using
filterwarnings.It also combines all missing keys into a single warning, instead of issuing a separate warning, but I'm not sure that's a good idea or not (this is a separate commit so it is easy to take it out).
Fix #7620