Description

stiege

opened on Nov 1, 2022

Issue body actions

Bug report

https://bugs.python.org/issue21197 added a lib64 symlink for compatibility on POSIX systems. venv's behaviour differs from virtualenvs in that virtualenv does a check to see if the filesystem is able to symlink (https://github.com/pypa/virtualenv/blob/b85542c31ca8afcff317e618da434f59fa06d122/src/virtualenv/info.py#L28-L47)

https://bugs.python.org/msg219258

If the filesystem does not support symlinks (i.e. FAT) the exception is unhandled and the process exits - leaving the virtual environment structure unfinished. The issue can be worked around by creating a directory in the symlink's location before invoking venv (

cpython/Lib/venv/__init__.py

Line 152 in a508631

if not os.path.exists(link_path): # Issue #21643

).

Ideally venv would do a similar check to virtualenv or silently ignore the exception as this is just for POSIX compatibility purposes anyway (and the edge-case is already ignored of the directory existing).

Your environment

root@650ae388ee44:~# python --version
Python 3.10.4
root@650ae388ee44:~# python -m venv venv --copies  # Throws an exception on FAT fs, venv unfinished
root@650ae388ee44:~# find venv/ -type l  # gah, a symlink
venv/lib64
root@650ae388ee44:~# rm -rf venv/
root@650ae388ee44:~# mkdir -p venv/lib64  # Workaround
root@650ae388ee44:~# python -m venv venv --copies
root@650ae388ee44:~# find venv/ -type l
root@650ae388ee44:~#

Activity

1. stiege

   added

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

   on Nov 1, 2022
2. akulakov commented on Dec 15, 2022

   

   akulakov

   on Dec 15, 2022

   Contributor

   More actions

   It seems like --copies shouldn't create symlinks anyway; can you provide the traceback? I don't have a windows system but i can look into this. Do you also get the same error with --symlinks ?

   [Edit: after posting I think I realized what you meant -- --copies does copy for some files but not for lib64. Should it also copy lib64?]
3. brettcannon commented on Mar 5, 2023

   

   brettcannon

   on Mar 5, 2023

   Member

   More actions

   It shouldn't copy lib64 because it symlinks to lib, so you're effectively copying site-packages which doesn't make sense since you now have two different places to potentially install which won't work.

   I think the real question is whether when people say --copies on Unix are they saying they don't want any symlinks or simply to not even attempt because I expect symlinking to fail? If it's the former then symlinking should be skipped, but if it's the latter then for compatibility the exception for failure should just be caught and ignored.
4. iritkatriel

   added

   stdlibStandard Library Python modules in the Lib/ directoryStandard Library Python modules in the Lib/ directory

   topic-venvRelated to the venv moduleRelated to the venv module

   on Nov 26, 2023
5. gaborbernat commented on Jun 5, 2026

   

   gaborbernat

   on Jun 5, 2026

   Contributor

   More actions

   The lib64 -> lib symlink that fails here was removed from venv entirely in 3.15 (gh-133951, #137139, commit a7a485558c0), so venv no longer creates that symlink and the unguarded failure on filesystems without symlink support (FAT, CIFS) can't occur — a venv on main now has only lib. That matches the point above that symlinking/copying lib64 doesn't make sense.

   Recommend closing as resolved (fixed by gh-133951).

   Reacted by Brett Cannon
6. brettcannon

   closed this as completedon Jun 8, 2026

Issue actions