Pip deprecation warnings not displayed by default · Issue #11330 · pypa/pip (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Closed
sbidoul opened this issue
Jul 31, 2022
· 20 comments · Fixed by #11333
Labels
A confirmed bug or unintended behavior
Comments
Description
Following #11229 the pip deprecation warnings are not displayed by default, because DeprecationWarnings are ignored by the default warning filters.
I propose to revert #11229 in pip 22.2.2 and we can think about a better solution for 22.3 or later.
Expected behavior
Pip deprecation warnings should be displayed with a default python installation, otherwise most users won't see them.
pip version
22.2
Python version
3
OS
any
How to Reproduce
...
Output
No response
Code of Conduct
- I agree to follow the PSF Code of Conduct.
This was referenced
Jul 31, 2022
Copying the problem from #11225. There is currently no good way to suppress pip’s deprecation warnings, even if they are expected for various reasons.
We can subclass from warning, and let user suppress PipDeprecationWarning?
Regardless, I’d prefer we unconditionally show warnings than not show them. ;)
FWIW, I've tried this:
❯ python -W 'ignore::pip._internal.utils.deprecation.PipDeprecationWarning' -m pip --version
Invalid -W option ignored: invalid module name: 'pip._internal.utils.deprecation'
...
I've not had time to dig further. So if no better low risk idea shows up I'm going to go ahead with #11333 for 22.2.2 and reopen #11225.
Just ignore PipDeprecationWarning, without any internal module path?
Nope, I had tried that too: Invalid -W option ignored: unknown warning category: 'PipDeprecationWarning'.
I can reproduce this in a standalone package:
ttt
__init__.py (contains "class W(Warning): pass")
__main__.py (contains a print("hi") statement)
❯ py -W ignore::ttt.W ttt
Invalid -W option ignored: invalid module name: 'ttt'
hi
I suspect this is a core Python bug, with -W not handling 3rd party module names for some reason.
Ah so the syntax seems pretty weird. https://docs.python.org/3/using/cmdline.html#cmdoption-w
So I think -W ignore::PipDeprecationWarning:pip._internal.utils.deprecation should work?
(I wonder if it’s worthwhile to make PipDeprecationWarning a top-level import so a user can write ignore:PipDeprecationWarning:pip)
❯ python -W ignore::PipDeprecationWarning:pip._internal.utils.deprecation -m pip --version Invalid -W option ignored: unknown warning category: 'PipDeprecationWarning' pip 22.3.dev0 from /Users/pradyunsg/Developer/github/pip/src/pip (python 3.10)
BTW, using the fully qualified category class name as category filter is PEP 230, but I could not find it in the official docs, so maybe that has never been implemented.
Well, then let's use UserWarning then.
❯ python -m pip --version DEPRECATION: AAA pip 22.3.dev0 from /Users/pradyunsg/Developer/github/pip/src/pip (python 3.10)
❯ python -W ignore::UserWarning -m pip --version pip 22.3.dev0 from /Users/pradyunsg/Developer/github/pip/src/pip (python 3.10)
❯ git diff src/pip/_internal/utils diff --git a/src/pip/_internal/utils/deprecation.py b/src/pip/_internal/utils/deprecation.py index 7964095ff..42f8b0738 100644 --- a/src/pip/_internal/utils/deprecation.py +++ b/src/pip/_internal/utils/deprecation.py @@ -13,7 +13,7 @@ DEPRECATION_MSG_PREFIX = "DEPRECATION: "
-class PipDeprecationWarning(DeprecationWarning): +class PipDeprecationWarning(UserWarning): pass
If we have a consistent prefix like "Pip:" for the message, people could also use something like -W ignore:Pip:UserWarning
-W ignore:Pip:UserWarning
We have DEPRECATION: , so...
❯ python -W 'ignore:DEPRECATION:UserWarning' -m pip --version pip 22.3.dev0 from /Users/pradyunsg/Developer/github/pip/src/pip (python 3.10)
Well, in that case, we can also change to a Warning:
❯ python -m pip --version DEPRECATION: AAA pip 22.3.dev0 from /Users/pradyunsg/Developer/github/pip/src/pip (python 3.10)
❯ python -W 'ignore:DEPRECATION' -m pip --version pip 22.3.dev0 from /Users/pradyunsg/Developer/github/pip/src/pip (python 3.10)
❯ g diff src/pip/_internal/utils diff --git a/src/pip/_internal/utils/deprecation.py b/src/pip/_internal/utils/deprecation.py index 7964095ff..72bd6f25a 100644 --- a/src/pip/_internal/utils/deprecation.py +++ b/src/pip/_internal/utils/deprecation.py @@ -13,7 +13,7 @@ DEPRECATION_MSG_PREFIX = "DEPRECATION: "
-class PipDeprecationWarning(DeprecationWarning): +class PipDeprecationWarning(Warning): pass
Simple enough :) Ok, merging #11333.
I really dislike suggesting either magic prefix or a non-pip-specific warning class though, since that could silence other meaningful warnings generated by vendor packages. (e.g. if something detects an environment configuration issue that has security implications)
Do you expect security issues to start with Deprecation, and somehow only occur for folks who are silencing the warning?
I expect deprecation issues to start with DEPRECATION, but a deprecation can be made for various reasons, including security issues. They don’t only occur for people silencing the warnings, but those who do silence will miss the chance to notice them.
I really dislike suggesting either magic prefix or a non-pip-specific warning class
I agree, but it appears that we're unable to do better because of the limitations of the core Python -W flag (combined with the core Python policy of suppressing deprecation warnings by default).
From #11229:
I’m not sure why this was not done in the first place—perhaps there were considerations I did not know.
Perhaps the issues with core Python's policy were the considerations here? I must admit, as it stands, I don't see how a user application can reasonably use the core DeprecationWarning class successfully...
I updated my comment in the original issue (#11225 (comment)) to mention the potential risk of hiding other important warnings.
I don't think there is anything else we need to do about this in 22.2.2.
If anyone thinks there is more to do for a future release, I suggest we open another issue to track the feature request.
inmantaci pushed a commit to inmanta/inmanta-core that referenced this issue
inmantaci pushed a commit to inmanta/inmanta-core that referenced this issue
Labels
A confirmed bug or unintended behavior