[Python-modules-team] Bug#958764: python3-pip: debundled _vendor packaging approach breaks usage of pip in environments

[Paul Ivanov]

Package: python3-pip
Version: 20.0.2-5
Severity: normal

Dear Maintainer,

Some tools that use pip rely on being able to use it  by adding its installed
location to the path of their environments.

One example is pipx.

$ pip3 --version
pip 20.0.2 from /usr/lib/python3/dist-packages/pip (python 3.8)

$ pip3 install pipx
...succeeds

$ export PATH=~/.local/bin:$PATH
$ pipx --version
0.15.1.3

$ pipx install cowsay
Traceback (most recent call last):
  File "/usr/lib/python3.8/runpy.py", line 193, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/usr/lib/python3.8/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/home/dummy/.local/pipx/shared/lib/python3.8/site-
packages/pip/__main__.py", line 16, in <module>
    from pip._internal.cli.main import main as _main  # isort:skip # noqa
  File "/home/dummy/.local/pipx/shared/lib/python3.8/site-
packages/pip/_internal/cli/main.py", line 10, in <module>
    from pip._internal.cli.autocompletion import autocomplete
  File "/home/dummy/.local/pipx/shared/lib/python3.8/site-
packages/pip/_internal/cli/autocompletion.py", line 9, in <module>
    from pip._internal.cli.main_parser import create_main_parser
  File "/home/dummy/.local/pipx/shared/lib/python3.8/site-
packages/pip/_internal/cli/main_parser.py", line 7, in <module>
    from pip._internal.cli import cmdoptions
  File "/home/dummy/.local/pipx/shared/lib/python3.8/site-
packages/pip/_internal/cli/cmdoptions.py", line 24, in <module>
    from pip._internal.exceptions import CommandError
  File "/home/dummy/.local/pipx/shared/lib/python3.8/site-
packages/pip/_internal/exceptions.py", line 10, in <module>
    from pip._vendor.six import iteritems
ModuleNotFoundError: No module named 'pip._vendor.six'


This was raised in a pipx issue [0] and in investigating it, I tracked it
down to the DEBUNDLE logic that gets patched to point to the python-wheels
folder.

Whereas with pip's code upstream (both vendored and debundled), adding the
site-packages folder containing a working version of pip will result in a being
able to use pip, this is not the case for Debian.

For pip as it is currently packaged in Debian, one has to also include all of
the wheels that get added to the path after importing pip._vendor. See an
example of such an approach in [1].

Would it be possible to keep the expected functionality provided by pip as
released upstream, perhaps by symlinking the wheels into the pip._vendor
directory?


0. https://github.com/pipxproject/pipx/issues/386
1. https://github.com/pipxproject/pipx/pull/388

best,
pi



-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.5.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-pip depends on:
ii  ca-certificates     20190110
ii  python-pip-whl      20.0.2-5
ii  python3             3.8.2-3
ii  python3-distutils   3.8.2-2
ii  python3-setuptools  45.2.0-1
ii  python3-wheel       0.34.2-1

Versions of packages python3-pip recommends:
ii  build-essential  12.8
ii  python3-dev      3.8.2-3

python3-pip suggests no packages.

-- no debconf information