pip 24.1b1 downgrade to pip 24.0 throws an exception

[notatallshaw]

Description

When you install pip 24.1 beta into Python 3.10 Linux environment and then try to downgrade to pip 24.0 you get an error, although it appears the downgrade works the error is rather unfriendly

Expected behavior

You can downgrade without exception

pip version

24.1b1

Python version

Python 3.10.14

OS

Linux

How to Reproduce

1. python -m venv .venv
2. source .venv/bin/activate
3. python -m pip install pip --upgrade
4. python -m pip install "pip>=0.0dev0" --upgrade
5. python -m pip install pip==24.0

Output

$ python -m pip install pip==24.0
Collecting pip==24.0
  Using cached pip-24.0-py3-none-any.whl.metadata (3.6 kB)
Using cached pip-24.0-py3-none-any.whl (2.1 MB)
Installing collected packages: pip
  Attempting uninstall: pip
    Found existing installation: pip 24.1b1
    Uninstalling pip-24.1b1:
      Successfully uninstalled pip-24.1b1
Successfully installed pip-24.0
Traceback (most recent call last):
  File "/home/damian/.pyenv/versions/3.10.14/lib/python3.10/runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/home/damian/.pyenv/versions/3.10.14/lib/python3.10/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/home/damian/opensource/contributions/pip/pip_beta_testing/.venv/lib/python3.10/site-packages/pip/__main__.py", line 24, in <module>
    sys.exit(_main())
  File "/home/damian/opensource/contributions/pip/pip_beta_testing/.venv/lib/python3.10/site-packages/pip/_internal/cli/main.py", line 80, in main
  File "/home/damian/opensource/contributions/pip/pip_beta_testing/.venv/lib/python3.10/site-packages/pip/_internal/cli/base_command.py", line 100, in main
    with self.main_context():
  File "/home/damian/opensource/contributions/pip/pip_beta_testing/.venv/lib/python3.10/site-packages/pip/_internal/cli/base_command.py", line 234, in _main
    return run(options, args)
  File "/home/damian/opensource/contributions/pip/pip_beta_testing/.venv/lib/python3.10/site-packages/pip/_internal/cli/index_command.py", line 172, in handle_pip_version_check
  File "/home/damian/opensource/contributions/pip/pip_beta_testing/.venv/lib/python3.10/site-packages/pip/_internal/cli/index_command.py", line 136, in _pip_self_version_check
  File "/home/damian/opensource/contributions/pip/pip_beta_testing/.venv/lib/python3.10/site-packages/pip/_internal/self_outdated_check.py", line 20, in <module>
    from pip._internal.metadata.base import DistributionVersion
ImportError: cannot import name 'DistributionVersion' from 'pip._internal.metadata.base' (/home/damian/opensource/contributions/pip/pip_beta_testing/.venv/lib/python3.10/site-packages/pip/_internal/metadata/base.py)

### Code of Conduct

- [X] I agree to follow the [PSF Code of Conduct](https://www.python.org/psf/conduct/).

[ichard26]

Ugh, this is my fault. #12637 made the pip self-version check import pip._internal.self_outdated_check on demand. This blows up here as it imports the module after the downgrade, which is problematic as the older self-check logic is incompatible with the rest of the pip already loaded into memory.

TL;DR, lazy imports are unsafe when pip reinstalls itself. Solutions are:

• Disable the pip version check when installing pip
• Suppress ImportErrors and friends during the pip self-version check
• Revert Avoid network/index related imports for pip uninstall & list (unless necessary) #12637

I'd prefer option one, but I'll prepare the revert PR as stability is more important.

[notatallshaw]

Disable the pip version check when installing pip

Personally I think this makes logical sense anyway. If I am changing the version of pip I don't need pip to tell me that pip is outdated.

[notatallshaw]

And just to double emphasise, the impact is relatively minor here, the downgrade completes:

Successfully installed pip-24.0

The error is thrown after the install.

[ichard26]

Actually, I guess a valid third option is to suppress all exceptions encountered during the pip self-version check. AFAIK network errors are already suppressed (with a warning).

[ichard26]

OK I implemented option 1 locally, but one wrinkle is that it doesn't protect source dir downgrades from blowing up. It just blew up as I was running pip install . to test the patch. This is a lot better than nothing as most pip users do not install pip from an unnamed source, but probably still unacceptable.

[uranusjr]

Maybe we could keep the on-demand imports, but also add a check before installation to see if pip is going to be touched? If pip is going to be modified, we could eagerly import the things that generally need to be on-demand. This way the old modules would already be in memory and should be able to perform correctly.

[ichard26]

I've implemented option 3 in #12676 and @uranusjr's suggestion in #12684. Please take a look and verify that they actually fix the crash reliably.