Join GitHub today
supplying filterwarnings overrides default filters #4013
I'm really happy about pytest 3.8 and the work in #2908.
And now that I'm seeing warnings again, I realize how blissful ignorance is.
So I've gone through one project and fixed all of the deprecation warnings for the project under test (there are still many coming from other projects). In order to assert that the project no longer has any warnings, I added this to pytest.ini:
Now tests pass, but all of the deprecation warnings (from the dependencies) are suppressed. That wasn't what I'd intended by setting the project to error on warnings.
I don't think that's the right behavior. Instead, pytest should configure the filters for DeprecationWarnings and PendingDeprecationWarnings and then allow the user to override those filters but not suppress the defaults with any value.
If the project must suppress the defaults, the docs should at least describe what the defaults are so they can be copied into the configuration wishing to define other filters. I had to traverse to the source to determine what the defaults are:
Is there any reason not to always configure the defaults and allow overrides?
Indeed. When we introduced the warnings plugin a few versions back we had some serious regressions, so this time around I decided to be really conservative to minimize disruption.
The unittest module only changes the warnings filters to diplay deprecations if sys.warnoptions is set (usually by
So basically we only install the filters if the user did not specify any filter configuration themselves, either using pytest's mechanisms or python's own
But I agree with you that this is not ideal, because as you point out any customization effectively silences deprecation warnings again.
I believe that for