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 commented on Jan 18, 2026
This is a Fedora bug, please open it in their tracker.
CC @hroncok
hroncok commented on 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 commented on 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 commented on Jan 19, 2026
There are more problems with this.
Per documentation get_path_names is Return a tuple containing **all path names currently supported** in sysconfig. (emphasis added)
>>> pprint.pprint(sysconfig.get_path_names()) ('stdlib', 'platstdlib', 'purelib', 'platlib', 'include', 'scripts', 'data')>>> pprint.pprint(sysconfig.get_paths("venv")) {'data': '/usr', 'include': '/usr/include/python3.14', 'platinclude': '/usr/include/python3.14', 'platlib': '/usr/lib64/python3.14/site-packages', 'platstdlib': '/usr/lib64/python3.14', 'purelib': '/usr/lib/python3.14/site-packages', 'scripts': '/usr/bin', 'stdlib': '/usr/lib64/python3.14'} >>>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)
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 commented on 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 commented on Jan 20, 2026
#137139 @Cycloctane & @FFY00
StanFromIreland commented on Jan 20, 2026
Huh, wait, that's not in 3.14?
picnixz commented on Jan 20, 2026
Oh. I thought so... well anyway @FFY00 expertise would still be appreciated