You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Possible missing symlink to lib64 in user path schema on Linux Fedora 43, Python 3.14.2 #143989
I'm not sure if this is distribution specific problem or something is broken in the core, so I'm filing it here first. I'm also not sure if it's CPython per se or needs to go into PyPA (pip etc).
Python 3.14.2 (main, Dec 5 2025, 00:00:00) [GCC 15.2.1 20251111 (Red Hat 15.2.1-4)] on linux
Firstly, in the posix_user the platlib goes into lib, whereas in venv everything that isn't pure is going into lib64.
Secondly, in the venv, this doesn't really matter due to there being a symlink from lib64 to lib. However, in the posix_user the lib64 is simply missing from /home/arcivanov/.local/ while being referenced in posix_user schema as something that should exist.
Venv:
drwxr-xr-x 1 arcivanov arcivanov 374 Dec 9 09:34 bin
-rw-r--r-- 1 arcivanov arcivanov 69 Dec 9 09:34 .gitignore
drwxr-xr-x 1 arcivanov arcivanov 0 Dec 9 09:34 include
drwxr-xr-x 1 arcivanov arcivanov 22 Dec 9 09:34 lib
lrwxrwxrwx 1 arcivanov arcivanov 3 Dec 9 09:34 lib64 -> lib
-rw-r--r-- 1 arcivanov arcivanov 305 Dec 9 09:34 pyvenv.cfg
I disagree this is a Fedora-only bug, we do nothing special with posix_user. The values are implocitly from upstream Python built with the platlibdir option.
That said, I don't think this is a bug per se.
The directories in posix_user don't neccessarily exist. Unlike venv, which is managed by Python (and the link from lib64 to lib is created by Python as well), your home .local folder is not managed by Python. Python does not create the folders within unless you e.g. pip install into them, in which case it's probably pip that does that, not sure. If it created the symbolic link, it might break expectations by other non-Python things.
Before dismissal however, let me ask an important question: why do you need the link? What is your use case that is broken?
venv paths contains platinclude that isn't even in the list of the names supported.
The use case is I need to install an SO into a lib OR lib64 of the venv or user installation (depending on what the platform requires) so that it can be found there at the same relative location they would be found in under root prefix (e.g. /usr)
Activity
StanFromIreland commentedon Jan 18, 2026
This is a Fedora bug, please open it in their tracker.
CC @hroncok
hroncok commentedon Jan 18, 2026
Thanks for letting us know.
I disagree this is a Fedora-only bug, we do nothing special with posix_user. The values are implocitly from upstream Python built with the platlibdir option.
That said, I don't think this is a bug per se.
The directories in posix_user don't neccessarily exist. Unlike venv, which is managed by Python (and the link from lib64 to lib is created by Python as well), your home .local folder is not managed by Python. Python does not create the folders within unless you e.g. pip install into them, in which case it's probably pip that does that, not sure. If it created the symbolic link, it might break expectations by other non-Python things.
Before dismissal however, let me ask an important question: why do you need the link? What is your use case that is broken?
hroncok commentedon Jan 18, 2026
(I get the "this is inconsistent" part, but honestly I am afraid to touch this just because of that. The entire thing is very fragile.)
arcivanov commentedon Jan 19, 2026
There are more problems with this.
Per documentation
get_path_namesisReturn a tuple containing **all path names currently supported** in sysconfig.(emphasis added)venvpaths containsplatincludethat isn't even in the list of the names supported.The use case is I need to install an SO into a
libORlib64of thevenvoruserinstallation (depending on what the platform requires) so that it can be found there at the same relative location they would be found in under root prefix (e.g./usr)Fix lib64 sometimes not existing on Linux in User installations
Fix lib64 sometimes not existing on Linux in User installations
Fix lib64 sometimes not existing on Linux in User installations
picnixz commentedon Jan 20, 2026
We made a change in 3.14 where we removes some symlinks in venv. Can you find the commit and its authors?
StanFromIreland commentedon Jan 20, 2026
#137139 @Cycloctane & @FFY00
StanFromIreland commentedon Jan 20, 2026
Huh, wait, that's not in 3.14?
picnixz commentedon Jan 20, 2026
Oh. I thought so... well anyway @FFY00 expertise would still be appreciated