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 _______________________________________________ Python-modules-team mailing list Python-modules-team@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/python-modules-team