VerboseLogger intruduction breaks projects relying on logging.setLoggerClass()

[s0undt3ch]

Description

The VerboseLogger introduced in #9450 forces the call to init_logging() as soon as pip._internal is imported.

As you will likely argue, the moment code imports pip._internal they're messing with an internal API and they shouldn't be doing that.
Unfortunately, the Salt Project does that and while it expects to fix breakage on and off, because that API is not public, we were not expecting this kind of breakage. We also rely on a custom logging handler class.

Can this initialization be postponed/done at your CLI modules, forcing the initialization only when pip is being used from the CLI?

Expected behavior

An import to pip._internal not injecting it's own custom logging handler. That should be postponed to code which interfaces with the CLI, where it's going to be used

pip version

21.2.1

Python version

Does not matter

OS

Does not matter

How to Reproduce

Python 3.6.8 (default, Apr 15 2020, 09:32:35) 
[GCC 9.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import logging
>>> logging.getLoggerClass()
<class 'logging.Logger'>
>>> import pip
>>> logging.getLoggerClass()
<class 'logging.Logger'>
>>> import pip._internal
>>> logging.getLoggerClass()
<class 'pip._internal.utils._log.VerboseLogger'>
>>> 

Output

No response

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[pfmoore]

You should not be importing pip in your code, it's not supported. And this is one reason why, so that changes like this won't affect you. Please read the user guide for more details.

[s0undt3ch]

Closed as expected. We can't rely on your CLI usage approach, we need more "power".
We'll work around this issue.

[pradyunsg]

Please don't reference this issue in a commit message -- it causes unnecessary noise here every time you amend/rebase.