Pip is broken in most of the Python envs today

Today my previously working builds started exploding when using pip, like this:

$ pip --version
Traceback (most recent call last):
  File "/home/travis/virtualenv/python3.6.7/bin/pip", line 7, in <module>
    from pip._internal import main
  File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/pip/_internal/__init__.py", line 40, in <module>
    from pip._internal.cli.autocompletion import autocomplete
  File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/pip/_internal/cli/autocompletion.py", line 8, in <module>
    from pip._internal.cli.main_parser import create_main_parser
  File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/pip/_internal/cli/main_parser.py", line 12, in <module>
    from pip._internal.commands import (
  File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/pip/_internal/commands/__init__.py", line 6, in <module>
    from pip._internal.commands.completion import CompletionCommand
  File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/pip/_internal/commands/completion.py", line 6, in <module>
    from pip._internal.cli.base_command import Command
  File "/home/travis/virtualenv/python3.6.7/lib/python3.6/site-packages/pip/_internal/cli/base_command.py", line 25, in <module>
    from pip._internal.index import PackageFinder
ImportError: cannot import name 'PackageFinder'

Here’s an example instance: https://travis-ci.com/github/cherrypy/cheroot/jobs/364037184#L232.
Also, there’s a lot of jobs with the same problem in that build: https://travis-ci.com/github/cherrypy/cheroot/builds/176792255.

It does not explode on Python 3.8, 3.7, 3.5, and 3.4.
It is broken on Python 3.6 and Python 2.7 (at least).


adding /home/travis/virtualenv/python3.6.7 to cache

suggests that you’re messing with the virtualenv’s contents. When the cache is restored, you’re left with a mix of preinstalled and cached files, with unpredictable results in case of a slightest change.

1 Like

That’s an interesting suggestion. I haven’t considered the cache poisoning because this used to work well for year…

/me is going to clean the cache now

That’s why I wrote “in case of a slightest change” :wink:

Something as simple as upgrading Pip to a new version can break it if you mechanically restore new files on top of the old ones – because the package’s logic doesn’t expect anything extraneous to be present in its installation directory.

If you wish to save on module download and installation times, cache Pip’s cache instead of installation.

Yeah… I know. FWIW wiping the cache worked. Thanks again!