Description

arcivanov

opened on Jan 18, 2026

Issue body actions

Bug report

Bug description:

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

>>> pprint.pprint(sysconfig.get_paths("posix_user"))
{'data': '/home/arcivanov/.local',
 'include': '/home/arcivanov/.local/include/python3.14',
 'platlib': '/home/arcivanov/.local/lib/python3.14/site-packages',
 'platstdlib': '/home/arcivanov/.local/lib64/python3.14',
 'purelib': '/home/arcivanov/.local/lib/python3.14/site-packages',
 'scripts': '/home/arcivanov/.local/bin',
 'stdlib': '/home/arcivanov/.local/lib64/python3.14'}
>>> 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'}
>>> 

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

CPython versions tested on:

3.14

Operating systems tested on:

Linux

Activity

1. arcivanov

   added

   type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

   on Jan 18, 2026
2. StanFromIreland commented on Jan 18, 2026

   

   StanFromIreland

   on Jan 18, 2026

   Member

   More actions

   This is a Fedora bug, please open it in their tracker.

   CC @hroncok
3. StanFromIreland

   closed this as not plannedon Jan 18, 2026
4. hroncok commented on Jan 18, 2026

   

   hroncok

   on Jan 18, 2026

   Contributor

   More actions

   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?
5. hroncok commented on Jan 18, 2026

   

   hroncok

   on Jan 18, 2026

   Contributor

   More actions

   (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.)
6. arcivanov commented on Jan 19, 2026

   

   arcivanov

   on Jan 19, 2026

   ContributorAuthor

   More actions

   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)
7. StanFromIreland

   reopened this on Jan 19, 2026
8. arcivanov

   added 3 commits that reference this issue on Jan 19, 2026

   Fix lib64 sometimes not existing on Linux in User installations

   162f804

   Fix lib64 sometimes not existing on Linux in User installations

   33240de

   Fix lib64 sometimes not existing on Linux in User installations

   fd1fb82
9. picnixz commented on Jan 20, 2026

   

   picnixz

   on Jan 20, 2026

   Member

   More actions

   We made a change in 3.14 where we removes some symlinks in venv. Can you find the commit and its authors?
10. picnixz

    added

    topic-installation

    3.14bugs and security fixesbugs and security fixes

    3.15bugs and security fixesbugs and security fixes

    on Jan 20, 2026
11. StanFromIreland commented on Jan 20, 2026

    

    StanFromIreland

    on Jan 20, 2026

    Member

    More actions

    #137139 @Cycloctane & @FFY00
12. StanFromIreland commented on Jan 20, 2026

    

    StanFromIreland

    on Jan 20, 2026

    Member

    More actions

    Huh, wait, that's not in 3.14?
13. picnixz commented on Jan 20, 2026

    

    picnixz

    on Jan 20, 2026

    Member

    More actions

    Oh. I thought so... well anyway @FFY00 expertise would still be appreciated

Issue actions