pyvenv --symlinks option is a no-op?

[pitrou]

BPO	15281
Nosy	@loewis, @vsajip, @pitrou

^{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 = None
closed_at = <Date 2012-07-08.16:51:05.189>
created_at = <Date 2012-07-07.15:37:22.628>
labels = ['type-bug', 'library']
title = 'pyvenv --symlinks option is a no-op?'
updated_at = <Date 2013-04-15.21:57:13.080>
user = 'https://github.com/pitrou'

bugs.python.org fields:

activity = <Date 2013-04-15.21:57:13.080>
actor = 'piotr.dobrogost'
assignee = 'none'
closed = True
closed_date = <Date 2012-07-08.16:51:05.189>
closer = 'python-dev'
components = ['Library (Lib)']
creation = <Date 2012-07-07.15:37:22.628>
creator = 'pitrou'
dependencies = []
files = []
hgrepos = []
issue_num = 15281
keywords = []
message_count = 10.0
messages = ['164879', '164895', '164899', '164927', '164928', '164930', '165024', '186961', '186969', '187034']
nosy_count = 5.0
nosy_names = ['loewis', 'vinay.sajip', 'pitrou', 'python-dev', 'piotr.dobrogost']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue15281'
versions = ['Python 3.3']

[pitrou]

It seems that, regardless of whether I specify --symlinks or not, pyvenv always creates symlinks:

$ pyvenv-3.3 env 
$ tree env/
env/
|-- bin
|   |-- activate
|   |-- pydoc
|   |-- pysetup3
|   |-- python -> python3.3
|   |-- python3 -> python3.3
|   `-- python3.3 -> /home/antoine/opt/bin/python3.3
|-- include
|-- lib
|   `-- python3.3
|       `-- site-packages
`-- pyvenv.cfg

5 directories, 7 files

[loewis]

Try --no-symlinks.

[pitrou]

$ pyvenv-3.3 --no-symlinks env
usage: venv [-h] [--system-site-packages] [--symlinks] [--clear] [--upgrade]
            ENV_DIR [ENV_DIR ...]
venv: error: unrecognized arguments: --no-symlinks

:-)

[vsajip]

Following discussions on python-dev, the default is always to symlink, except on Windows (no support for true symlinks on XP and older) and Mac OS X (problems with framework builds). The --symlinks indicates, on those platforms where symlinks is not the default, to use symlinks anyway. This will most likely only be useful on Windows Vista, Windows 7 and Mac OS X with a non-framework build of Python.

[pitrou]

Following discussions on python-dev, the default is always to symlink,
except on Windows (no support for true symlinks on XP and older) and
Mac OS X (problems with framework builds). The --symlinks indicates,
on those platforms where symlinks is not the default, to use symlinks
anyway. This will most likely only be useful on Windows Vista, Windows
7 and Mac OS X with a non-framework build of Python.

Ok, then it might be nice to make the usage string (which is printed
with pyvenv --help) clearer.

[vsajip]

Ok, then it might be nice to make the usage string (which is printed
with pyvenv --help) clearer.

Fair point, I'll update the help text to be clearer.

[python-dev]

New changeset 9c345b4bd97e by Vinay Sajip in branch 'default':
Closes bpo-15281, bpo-15283: Don't make venv scripts executable, but copy source mode instead, and provide better help for pyvenv.
http://hg.python.org/cpython/rev/9c345b4bd97e

[piotrdobrogost]

Following discussions on python-dev, the default is always to symlink,
except on Windows (no support for true symlinks on XP and older) and

In this case couldn't symlinks be automatically used on Windows Vista or newer?

[vsajip]

In this case couldn't symlinks be automatically used on Windows Vista or newer?

It seems simpler if the default behaviour is the same on all Windows flavours - you can specify --symlinks if you're on Windows Vista or later.

[piotrdobrogost]

It's simpler but is it better this way? I doubt. I think we should take advantage of symlinks whenever we can and only fallback to copying if they are not available.