Package: python3-pip Version: 18.1-5 Severity: important Dear Maintainer,
I spent a bit of time discovering the nature of this problem today. I have come to rely on the --root option with "pip install" (or equivalent python invocation) being a generally satisfactory way of installing packages into an alternate filesystem root, this having been tested on Red Hat's distribution offerings. When attempting to use the --root option on Debian, instead of getting a hierarchy like this... root/usr/local/... ...I get something like this: root/home/me/.local/... For example: pip3 install --root XXX biopython This produces... XXX/home/me/.local/lib/python3.7/site-packages/ At first, I thought that pip had changed its behaviour, as it often seems to, with advice strewn across the Internet rapidly becoming obsolete. But it turns out that the set_user_default.patch is actually responsible. Obviously, there is a workaround for the behaviour introduced by this patch: specifying --system or, perhaps, --no-user. But the former option is not understood by other distributions or vanilla pip, so it is non-standard and will break scripts. I guess that --no-user is meant to resolve this, although the online documentation for recent pip versions doesn't seem to mention it, and since the patch changes the behaviour of --no-user, I start to doubt if I could rely on that, either. Clearly, when specifying an installation root explicitly, the user is not likely to be looking to reproduce their "local" package hierarchy: they want to produce a genuine filesystem hierarchy, perhaps for populating chroots or virtual machines, as the option is meant to. This patch breaks this expected behaviour. One could argue that the logic featured in the patch, testing for a virtualenv or for root, is sufficient to detect whether someone is actually populating a genuine filesystem hierarchy and that one might use fakeroot as an unprivileged user to trigger the appropriate condition. While this might suit some users, there is really no reason why an arbitrary user could not populate usr/local in any given filesystem. Obstructing this makes the patch a vehicle for some rather prescriptive policy, and it also obstructs other applications that do not involve some form of virtualisation where the invoking user will be the owner of the files that are created. Please consider correcting the patch to make --root behave in a way that is consistent with other distributions and the upstream software. Working with Python packaging software is frustrating enough with the constant churn, parade of tools, and often baroque (but flawed) solutions. Having distributions (and hosting providers, on occasion) introduce additional, unexpected complications makes the use of these tools even more stressful and unpleasant. I am sorry if this report causes anyone any inconvenience or is generally not regarded as being helpful. Paul -- System Information: Debian Release: 10.10 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.5.0-0.bpo.2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (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 20200601~deb10u2 ii python-pip-whl 18.1-5 ii python3 3.7.3-1 ii python3-distutils 3.7.3-1 Versions of packages python3-pip recommends: ii build-essential 12.6 ii python3-dev 3.7.3-1 ii python3-setuptools 40.8.0-1 ii python3-wheel 0.32.3-2 python3-pip suggests no packages. -- no debconf information
