No longer override existing warning filters during warnings capture

[nicoddemus]

In the end it was possible to actually fix the existing behavior. I checked and it no longer breaks SQLAlchemy test suite which was the original post on #2430.

As a downside/side-effect, this no longer automatically captures deprecation warnings because we want to play safe and don't try to mess the existing filters, but I believe we can review this in the future if we like.

Fix #2430

[coveralls]

Coverage decreased (-0.0008%) to 92.236% when pulling c6774cc on nicoddemus:warnings-remove-filter into 6117930 on pytest-dev:master.

[coveralls]

Coverage decreased (-0.0008%) to 92.236% when pulling db8d83a on nicoddemus:warnings-remove-filter into 6117930 on pytest-dev:master.

[The-Compiler]

LGTM as-is - and with --pythonwarnings error I still get an exception with DeprecationWarnings like expected.

[nicoddemus]

@The-Compiler would you do the honors of merging it then? 😁

[blueyed]

What still seems to be problematic is:

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

With or without this in setup.cfg:

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

I want to use this method to filter out DeprecationWarnings based on where they are coming from.

[nicoddemus]

@blueyed thanks for the feedback.

Can you provide more info about what you intend with that? I'm not familiar with logging.captureWarnings and I'm short on time at the moment to look it up.

Also, do you feel this should block a new release? And do you have a suggestion on how to implement what you want in regards to logging vs warnings?

(Sorry for leaving this questions here, just that I have to leave for a meeting and will be out for a few hours)

[RonnyPfannschmidt]

@nicoddemus logging.captureWarnings replaces the warnings.show function with something that redirects to logging

[nicoddemus]

Rebased and updated to add a news fragment. 👍

[nicoddemus]

Thanks @RonnyPfannschmidt.

Hmmm that feels like some additional things are still needed. @blueyed do you feel this should hold the release or is something we can tackle afterwards without changing current behavior? My feeling is the former, but would like to hear your opinion first.

[coveralls]

Coverage decreased (-0.0008%) to 92.236% when pulling f591c6d on nicoddemus:warnings-remove-filter into ee0844d on pytest-dev:master.

[blueyed]

I think it should not hold back a release probably, since it fixes more crucial things already.

As for logging.captureWarnings: it monkeypatches warnings.showwarning to log them instead, which then allows for more fine-grained filtering.
pytest could maybe check if logging._warnings_showwarning is None? (which means it is not patched to go through logging)

[nicoddemus]

I think it should not hold back a release probably, since it fixes more crucial things already.

Thanks! Would you mind opening a separate issue for the logging and warning support? We can move this discussion there. 👍

[blueyed]

*except for DeprecationWarning and PendingDeprecationWarning

[blueyed]

s/override/overrides/ ?

[blueyed]

s/Note as/Note that/

[nicoddemus]

Thanks @blueyed, applied all your suggestions. 👍

Unless someone else tells otherwise, I will merge this as soon as CI passes again. Thanks everyone for the reviews.

[coveralls]

Coverage decreased (-0.0008%) to 92.236% when pulling 32e2642 on nicoddemus:warnings-remove-filter into 454426c on pytest-dev:master.

[hynek]

I think this might be doing too much? pytest 3.1.1 is silencing ResourceWarnings by default now which is a pity. In any case it seems at odds with the docs?

platform darwin -- Python 3.6.1, pytest-3.1.1, py-1.4.33, pluggy-0.4.0
rootdir: /Users/hynek/Work/epp_proxy, inifile: setup.cfg
plugins: catchlog-1.2.2, asyncio-0.6.0, hypothesis-3.11.1

I hope I’ve reverted to the old behavior by using:

filterwarnings =
    once::Warning