venv should create relative symlinks where possible

[warsaw]

BPO	23399
Nosy	@warsaw, @vsajip, @dstufft
Files	venv.patch

^{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 = <Date 2015-02-06.17:04:11.532>
created_at = <Date 2015-02-06.00:03:01.395>
labels = ['type-bug', 'library']
title = 'venv should create relative symlinks where possible'
updated_at = <Date 2015-02-14.17:39:00.638>
user = 'https://github.com/warsaw'

bugs.python.org fields:

activity = <Date 2015-02-14.17:39:00.638>
actor = 'berker.peksag'
assignee = 'vinay.sajip'
closed = True
closed_date = <Date 2015-02-06.17:04:11.532>
closer = 'barry'
components = ['Library (Lib)']
creation = <Date 2015-02-06.00:03:01.395>
creator = 'barry'
dependencies = []
files = ['38023']
hgrepos = []
issue_num = 23399
keywords = ['patch']
message_count = 3.0
messages = ['235457', '235473', '235489']
nosy_count = 4.0
nosy_names = ['barry', 'vinay.sajip', 'python-dev', 'dstufft']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue23399'
versions = ['Python 3.4', 'Python 3.5']

[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.

[vsajip]

LGTM.

[python-dev]

New changeset 6b8d95c12eaf by Barry Warsaw in branch '3.4':
Issue bpo-23399: pyvenv creates relative symlinks where possible.
https://hg.python.org/cpython/rev/6b8d95c12eaf

New changeset 9e6f79495e0b by Barry Warsaw in branch 'default':
Issue bpo-23399: pyvenv creates relative symlinks where possible.
https://hg.python.org/cpython/rev/9e6f79495e0b

New changeset 7a82b1539401 by Barry Warsaw in branch '3.4':
Issue bpo-23399: pyvenv creates relative symlinks where possible.
https://hg.python.org/cpython/rev/7a82b1539401