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
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee='https://github.com/vsajip'closed_at=<Date2015-02-06.17:04:11.532>created_at=<Date2015-02-06.00:03:01.395>labels= ['type-bug', 'library']
title='venv should create relative symlinks where possible'updated_at=<Date2015-02-14.17:39:00.638>user='https://github.com/warsaw'
There is a subtle behavior difference between virtualenv and pyvenv. When you create a venv with virtualenv, the symbolic links files <venv>/bin are relative, while they are absolute with pyvenv. This means that virtual environments created with virtualenv can be relocated (modulo the #! lines of the script, but let's not worry about that for now), but virtual environments created with pyvenv cannot be relocated.
With pyvenv, you also have <venv>/lib64 pointing to an absolute path.
AFAICT, there's no good reason why the symlink targets must be absolute paths. Relative paths work just fine for virtualenv and they should work fine for pyvenv.
This patch changes the lib64 and <venv>/bin/* symlinks to be relative. There should be no change when symlinks are disabled or are unavailable.
One remaining question is whether /bin/python itself should be relative. In virtualenv, even with something like -p /usr/bin/python3.4 you still get a relative link. /bin/python points outside of the venv, so the question is whether the $PATH-dependent behavior of virtualenv is worthwhile or not. My patch does not change this symlink.
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: