Pip deprecation warnings not displayed by default

[sbidoul]

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.

[uranusjr]

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.

[pradyunsg]

We can subclass from warning, and let user suppress PipDeprecationWarning?

[pradyunsg]

Regardless, I’d prefer we unconditionally show warnings than not show them. ;)

[sbidoul]

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.

[pradyunsg]

Just ignore PipDeprecationWarning, without any internal module path?

[sbidoul]

Nope, I had tried that too: Invalid -W option ignored: unknown warning category: 'PipDeprecationWarning'.

[pfmoore]

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.

[uranusjr]

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)

[pradyunsg]

❯ 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)

[sbidoul]

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.

[pradyunsg]

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
 

[pfmoore]

If we have a consistent prefix like "Pip:" for the message, people could also use something like -W ignore:Pip:UserWarning

[pradyunsg]

-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)

[pradyunsg]

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
 

[sbidoul]

Simple enough :) Ok, merging #11333.

[uranusjr]

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)

[pradyunsg]

Do you expect security issues to start with Deprecation, and somehow only occur for folks who are silencing the warning?

[uranusjr]

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.

[pfmoore]

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...

[sbidoul]

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.