Your message dated Sat, 25 Apr 2020 10:34:02 -0400
with message-id <58839866.iLgyPFC6jr@sk-desktop>
and subject line re: python3-pip: debundled _vendor packaging approach breaks
usage of pip in environments
has caused the Debian Bug report #958764,
regarding python3-pip: debundled _vendor packaging approach breaks usage of pip
in environments
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
958764: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958764
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
On Fri, 24 Apr 2020 23:37:13 -0700 Paul Ivanov <p...@berkeley.edu> wrote:
> 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.
...
>
> 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?
Maintaining symlink farms is inherently difficult and unreliable. Debian used
to use a similar approach to support multiple python2 versions and it never
worked well. I would be reluctant to use such an approach.
I checked with a pip upstream developer on IRC and his view is that what pipx
is doing is not supported by upstream:
> <ScottK> dstufft: If an program external to pip tries to use one of pip's
> vendored libraries directsly (e.g. from pip._vendor.six import iteritems)
> this won't work on Debian because we don't put the wheels in the pip
> package tree (they are in /usr/share/python-wheels). From your point of
> view upstream, if another package is doing such a thing are they
> unreasonably mucking about in pip internals and if it breaks it's their
> problem or is it something reasonable that they should be able to rely on
> and we should try to support?
> <dstufft> ScottK: upstrem does not support people importing pip internals
> /vendored libs
> <dstufft> we moved *everything* into a _ directory just to make this obvious
It may be that this pipx bug is only apparent on Debian and its derivatives
because we rely on the pip unbundle logic, but what pipx is doing is
unsupported upstream, so I don't think we can support it either.
Sorry I didn't have a more positive answer.
Scott K
signature.asc
Description: This is a digitally signed message part.
--- End Message ---
