Skip to content
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

warnings: support for logging.captureWarnings #2449

Closed
blueyed opened this issue May 30, 2017 · 5 comments
Closed

warnings: support for logging.captureWarnings #2449

blueyed opened this issue May 30, 2017 · 5 comments
Labels
plugin: warnings related to the warnings builtin plugin type: enhancement new feature or API change, should be merged into features branch

Comments

@blueyed
Copy link
Contributor

blueyed commented May 30, 2017

Moved from #2445 (comment):

The warnings plugin does not handle the case where the logging module's captureWarnings mechanism is used to route warnings through the logging module, and therefore allows to filter them:

logging.captureWarnings(True)
logging.getLogger('py.warnings').addFilter(filter_deprecation_warnings)

logging.captureWarnings monkeypatches warnings.showwarning (in Python 3.6) to log them instead (as a warning).
pytest could maybe check if logging._warnings_showwarning is not None to detect if warnings are supposed to go through logging.

With or without this in setup.cfg:

[tool:pytest]
filterwarnings =
    once::DeprecationWarning
    once::PendingDeprecationWarning

This mechanism is useful if you want to have fine-grained support on filtering, e.g. based on some (dynamic) path in the warning message.

I am not sure if it is worth the effort to do something in this regard, and if so what the best option would be: maybe transferring it into a log record and see if the py.warnings handlers would filter them?

@nicoddemus
Copy link
Member

Thanks for posting the issue @blueyed.

IIUC the idea is for pytest to no longer capture warnings if logging.captureWarnings is set, IOW, just let the logging module handle warnings itself?

Just to make sure I understand the issue: if you disable the warnings plugin using -p no:warnings, the logging methods works as usual correct?

@nicoddemus nicoddemus added type: enhancement new feature or API change, should be merged into features branch plugin: warnings related to the warnings builtin plugin labels May 30, 2017
@blueyed
Copy link
Contributor Author

blueyed commented May 30, 2017

Yes, and yes.

It is really a corner case, and I am going to remove this from the affected project anyway, but rather rely on what filtering warnings provides (via pytest's settings also).

@nicoddemus
Copy link
Member

Would it be sufficient to mention this as a blurb in the docs, or do you feel we need additional support in the code?

@blueyed
Copy link
Contributor Author

blueyed commented May 30, 2017

Don't let this hold back a release, not even for the blurb in the docs, please.

I will have to think myself (and would appreciate any input of course) about how this should get handled / documented: after all you want to filter warnings by redirecting them through logging.

The issue here is that warnings.catch_warnings (used by pytest) disables that.
So it might even be considered to be an issue in the stdlib - depending on where you look at it from. I can see that you really might want to catch all warnings with that.

@nicoddemus
Copy link
Member

Don't let this hold back a release, not even for the blurb in the docs, please.

Docs should not hold a release, given that they are published directly from master. 😉

I will have to think myself (and would appreciate any input of course) about how this should get handled / documented: after all you want to filter warnings by redirecting them through logging.

I think just documenting this use case in warnings.rst might be enough, something like a blurb/section stating to disable the plugin if you are using this feature from logging.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
plugin: warnings related to the warnings builtin plugin type: enhancement new feature or API change, should be merged into features branch
Projects
None yet
Development

No branches or pull requests

2 participants