-
-
Notifications
You must be signed in to change notification settings - Fork 30.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sysconfig's posix_user scheme has different platlib value to distutils's unix_user #89023
Comments
On POSIX, the user scheme has a different 'platlib' location between distutils and sysconfig, dispite the comment claiming they should be the same. This can be reproduced on Fedora 34's stock Python 3.9: $ docker run -it --rm -h=p fedora:34 bash
...
[root@p /]# yum install python3 -y
...
[root@p /]# type python3
python3 is hashed (/usr/bin/python3)
[root@p /]# python3 -V
Python 3.9.6
[root@p /]# python3.9 -q
>>> from distutils.command.install import install
>>> from distutils.dist import Distribution
>>> c = install(Distribution())
>>> c.user = True
>>> c.finalize_options()
>>> c.install_platlib
'/root/.local/lib/python3.9/site-packages'
>>> import sysconfig
>>> sysconfig.get_path('platlib', 'posix_user')
'/root/.local/lib64/python3.9/site-packages' This issue was introduced by the sys.platlibdir value, and its usage in distutils and sysconfig. sysconfig sets posix_user's lib paths like this:
Lines 100 to 108 in a40675c
But distutils naively sets both to the same value that does not account for platlibdir:
cpython/Lib/distutils/command/install.py Lines 68 to 87 in a40675c
causing the mismatch, dispite the comment above clearly indicating the values are supposed to be the same. This was introduced in bpo-1294959 which changed the platlib template to depend on sys.platlibdir, so a mismatch happens when the value of sys.platlibdir is not 'lib'. (Adding frenzy and vstinner to the nosy list since you introduced the comment in distutils and the sys.platlibdir change, respectively.) |
sys.platlibdir was introduced to install libraries in /usr/lib64 rather than /usr/lib. I'm not sure if it should be used to install libraries in $HOME/.local/lib64 rather than $HOME/.local/lib. Previously, Fedora already used $HOME/.local/lib and $HOME/.local/lib64 is not in the sys.path. Does the site module add $HOME/.local/lib64 to sys.path if it exists? |
This was also briefly discussed in bpo-1294959, but did not go through since “changing posix_user should have no impact on end users”.
It does not, only lib is checked right now. Lines 288 to 298 in c7ea1e3
---- There are two possible solutions from what I can tell. We could just make posix_user match posix_prefix and always respect sys.platlibdir. This could be confusing to existing Python 3.9 users however since many of them already pip-installed things into ~/.local/lib and this would make their user-site packages split in two locations. The other would be to restore the pre-3.9 behaviour in sysconfig to use lib instead of depending on sys.platlibdir. I don’t know who uses sysconfig right now and can’t say what would break, but for pip this would be less disruptive since it currently installs things into ~/.local/ib (provided by distutils). |
Installing to ~/.local/lib works, installing to ~/.local/lib64 breaks things, as it is not on sys.path. I agree that restoring the pre-3.9 behavior in sysconfig to use lib instead of depending on sys.platlibdir is a better fix, at least for 3.9 and 3.10. We can redesign things in 3.11 (but I wouldn't). |
I’ve updated the linked PR to change sysconfig instead to not use sys.platlibdir when generating the posix_user scheme. This means posix_user would behave the same in 3.9+ as 3.8 and prior. |
Marking as *potential* release blocker for 3.10. Pablo, without this change the newest pip (with [PR 10358]) will not work on Python 3.10 built --with-platlibdir.
So, if this isn't merged in 3.10, either pip or downstreams will need to implement a workaround. (If pip doesn't hold off, downstreams that build --with-platlibdir will likely carry this exact patch.) Note that there's a similar bug in bpo-45035 |
IIUC we need to backport PR27655 to 3.10 no? Or do we need something else? |
Possibly together with PR28011. |
Petr, is something left to do for this release blocker? I am planning to start the release if everything is OK |
I believe everything is in order now. |
See also the email on python-dev: |
Let's continue the discussion for the unix_home scheme in bpo-45035. |
There seem to be a regression in test_user_similar: https://bugs.python.org/issue45136 |
I marked bpo-45136 as a duplicate of this issue. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: