Disable all third-party warnings
See original GitHub issueHi. I’m using pytest 5.2.1 on NixOS. When testing a library, I get a lot of deprecation warnings from third party libraries that I have no control over. Is there some way to set up a warnings filter to only show warnings originating in the module I’m working on?
I was surprised that I couldn’t find a pre-existing issue discussing this. Maybe I just didn’t search for the right terms. If there already is one, please point me in the right direction.
`pip list`
Package Version
------------------ -------------------
aiohttp 3.6.2
aiohttp-cors 0.7.0
appdirs 1.4.3
astroid 2.3.2
async-timeout 3.0.1
atomicwrites 1.3.0
attrs 19.3.0
backcall 0.1.0
backports-abc 0.5
beautifulsoup4 4.8.1
black 19.10b0
Bottleneck 1.2.1
certifi 2019.9.11
cffi 1.13.1
chardet 3.0.4
Click 7.0
coverage 4.5.4
cryptography 2.8
cycler 0.10.0
decorator 4.4.0
Deprecated 1.2.6
dill 0.3.1.1
docutils 0.15.2
ecdsa 0.13.3
et-xmlfile 1.0.1
funcsigs 1.0.2
future 0.18.1
html5lib 1.0.1
httpretty 0.9.7
idna 2.8
importlib-metadata 0.23
ipython 7.8.0
ipython-genutils 0.2.0
isort 4.3.21
jdcal 1.4.1
jedi 0.15.1
joblib 0.14.0
kiwisolver 1.1.0
lazy-object-proxy 1.4.2
lxml 4.4.1
lz4 2.1.10
matplotlib 3.1.1
mccabe 0.6.1
mock 3.0.5
more-itertools 7.2.0
multidict 4.5.2
multiprocess 0.70.9
networkx 2.4
nix-bisect 0.1.0
nose 1.3.7
notmuch 0.29.2
numexpr 2.7.0
numpy 1.17.3
olefile 0.46
openpyxl 3.0.0
packaging 19.2
pandas 0.25.2
parso 0.5.1
path.py 12.0.1
pathspec 0.6.0
pbr 5.4.3
pexpect 4.7.0
pickleshare 0.7.5
Pillow 6.2.1
pip 19.3.1
pluggy 0.13.0
prompt-toolkit 2.0.10
psutil 5.6.3
ptyprocess 0.6.0
py 1.8.0
pyasn1 0.4.7
pycairo 1.18.1
pycallgraph 1.0.1
pycparser 2.19
pydot 1.4.1
PyGithub 1.44
Pygments 2.4.2
PyGObject 3.32.1
pygraphviz 1.5
PyJWT 1.7.1
pylint 2.4.3
pyOpenSSL 19.0.0
pyparsing 2.4.2
PySocks 1.7.0
pytest 5.2.1
python-dateutil 2.8.0
python-jose 3.0.1
pytz 2019.3
r2pipe 1.4.2
regex 2019.8.19
requests 2.22.0
rsa 4.0
scipy 1.3.1
setuptools 41.4.0.post20191022
setuptools-scm 3.3.3
singledispatch 3.4.0.3
six 1.12.0
soupsieve 1.9.4
SQLAlchemy 1.3.10
tables 3.6.1
toml 0.10.0
tornado 5.1
traitlets 4.3.3
typed-ast 1.4.0
urllib3 1.25.6
wcwidth 0.1.7
webencodings 0.5.1
wrapt 1.11.2
xlrd 1.2.0
xlwt 1.3.0
yarl 1.3.0
zipp 0.6.0
Issue Analytics
- State:
- Created 4 years ago
- Reactions:23
- Comments:13 (8 by maintainers)
Top Results From Across the Web
How do you suppress all 3rd party compile time warnings in ...
I've heard this is a problem with other 3rd party libraries like Qt. All great libraries. How can I suppress all 3rd party...
Read more >Disabling Intellisense warnings for third party libraries - MSDN
I'm working on a C++ project that's in the process of migrating from Visual Studio 2017 to 2019. In the project we're using...
Read more >Disabling warnings from legacy and third-party header files
In fact, in some projects, I have enabled the “Treat Warnings as Errors” option, to prevent any warnings from inadvertently slipping through. ( ......
Read more >How to disable a warning which gets re-enabled in third-party ...
The only workable technique I have (so far) come up with is to explicitly disable the relevant warnings before inclusion of the '3rd-Party'...
Read more >How to Disable a Warning in C++
Remember, in Visual Studio warnings are identified with numbers, not names. ... All in all, this is not so complicated. But what if...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I don’t think that solves my issue, since that would also silence DeprecationWarnings that are raised by some of our code. Those would not be raised in our module, but triggered by a line in our module. So
Should raise a warning in pytest, since it is something we should fix.
Should not raise a warning, since it is something that a third party (
other_library
) should fix.I was looking for a solution to this and this thread came up in Google. I was able to do what I needed with the standard lib warning filter in pytest similar to what Zac suggested.
In my case, I was calling a scipy function that was deprecated, and I was also calling other packages that called this same scipy function. Adding this filter silenced the warnings coming from calls in other packages, but left the warning from where I was calling it in
mymodule
.I think this depends on the packages that are emitting the warning setting the
stacklevel
when they callwarnings.warn()
so that it points to your code. If they set it too low, you may silence their warning even when it was triggered by your code.