question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

RemovedInPytest4Warning via _pytest\compat.py:321

See original GitHub issue

There are many RemovedInPytest4Warnings with pytest’s own tests, e.g.:

c:\projects\pytest\.tox\py36\lib\site-packages\_pytest\compat.py:321: RemovedInPytest4Warning: usage of Session.Class is deprecated, please use pytest.Class instead
360  return getattr(object, name, default)
361

(via https://ci.appveyor.com/project/pytestbot/pytest/builds/19474342/job/c83h5n8ne3snvf8o#L359)

Are those expected?

I would assume pytest should not causes warnings itself.

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Comments:17 (15 by maintainers)

github_iconTop GitHub Comments

1reaction
nicoddemuscommented, Oct 25, 2018

Created #4236 to adjust the stack level.

1reaction
Zac-HDcommented, Oct 19, 2018

That only applies after pytest has finished the configure stage though, right? In the configure stage, _issue_config_warning downgrades warnings from errors to capturing them, even if we run with python -Werror -m pytest. IMO we should

  • have a minimal dependency subset of the tests that we can run with Python-level warnings-as-errors
  • issue a warning directly from _issue_config_warning if warnings have already been configured
  • consider silencing warnings at the origin where we are using deprecated APIs for compatibility only

I’m poking at some of these now; I’ll update with results when I have some.


diff --git a/src/_pytest/warnings.py b/src/_pytest/warnings.py
index 6c4b921..e98d56a 100644
--- a/src/_pytest/warnings.py
+++ b/src/_pytest/warnings.py
@@ -165,8 +165,12 @@ def _issue_config_warning(warning, config):
     :param config:
     """
     with warnings.catch_warnings(record=True) as records:
-        warnings.simplefilter("always", type(warning))
+        # Set this warning to 'always', unless warnings have been configured
+        # at the interpreter level with e.g. -Werror or PYTHONWARNINGS=ignore
+        if sys.warnoptions:
+            warnings.simplefilter("always", type(warning))
         warnings.warn(warning, stacklevel=2)
-    config.hook.pytest_warning_captured.call_historic(
-        kwargs=dict(warning_message=records[0], when="config", item=None)
-    )
+    if records:
+        config.hook.pytest_warning_captured.call_historic(
+            kwargs=dict(warning_message=records[0], when="config", item=None)
+        )

Pretty sure this works but the setup to test it is awfully convoluted. I’ll leave it there for now before it turns into a serious un-fun slog.

Read more comments on GitHub >

github_iconTop Results From Across the Web

No results found

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found