Skip to content

Possible missing symlink to lib64 in user path schema on Linux Fedora 43, Python 3.14.2 #143989

Open

Description

@arcivanov

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. StanFromIreland commented on Jan 18, 2026

    @StanFromIreland
    Member

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

    CC @hroncok

  2. hroncok commented on Jan 18, 2026

    @hroncok
    Contributor

    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?

  3. hroncok commented on Jan 18, 2026

    @hroncok
    Contributor

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

  4. arcivanov commented on Jan 19, 2026

    @arcivanov
    ContributorAuthor

    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)

  5. picnixz commented on Jan 20, 2026

    @picnixz
    Member

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

  6. StanFromIreland commented on Jan 20, 2026

    @StanFromIreland
    Member
  7. StanFromIreland commented on Jan 20, 2026

    @StanFromIreland
    Member

    Huh, wait, that's not in 3.14?

  8. picnixz commented on Jan 20, 2026

    @picnixz
    Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    3.14bugs and security fixes3.15bugs and security fixestopic-installationtype-bugAn unexpected behavior, bug, or error

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions