[issue18807] Allow venv to create copies, even when symlinks are supported

Barry A. Warsaw added the comment: The os.chmod() will fail if path is a symlink. At the very least it must be guarded by a `not os.path.islink()` call like above it. I'll add this check to 3.4 and 3.5. -- nosy: +barry ___ Python tracker

[issue18807] Allow venv to create copies, even when symlinks are supported

Vinay Sajip added the comment: I've made the change - not exactly the same as your patch, which was missing an os.chmod() and doing an unnecessary os.path.join() - but thanks for submitting a patch :-). However, note that on 64-bit Linux systems (actually any POSIX other than OS X) a symlink

[issue18807] Allow venv to create copies, even when symlinks are supported

Roundup Robot added the comment: New changeset ce1b8b2ddf07 by Vinay Sajip in branch '3.4': Issue #18807: If copying (no symlinks) specified for a venv, then the python interpreter aliases (python, python3) are now created by copying rather than symlinking. http://hg.python.org/cpython/rev/ce1b

[issue18807] Allow venv to create copies, even when symlinks are supported

Dominic Cerquetti added the comment: Ok cool, as you said line 215 then seems to be the only one that needs it. -- ___ Python tracker ___

[issue18807] Allow venv to create copies, even when symlinks are supported

Dominic Cerquetti added the comment: Preliminary patch for line 215, per earlier description. While this doesn't appear to break anything and creates both copies and symlinks correctly, I do have these four failing unit tests: test_multiprocessing_fork test_multiprocessing_forkserver test_mul

[issue18807] Allow venv to create copies, even when symlinks are supported

Vinay Sajip added the comment: While you may be right about line 215, line 147 isn't analogous, because in the latter case it's a symlink to a directory. We don't really want the entire lib directory tree *copied* into lib64 (and in any case, the populating of lib will happen much after venv c

[issue18807] Allow venv to create copies, even when symlinks are supported

Dominic Cerquetti added the comment: Requesting re-open of this issue, using --closes to force no symlinks to be created still results in venv trying to create symlinks. I'm using Python 3.4 with the following command inside a vagrant Ubuntu 14.04 virtualbox image. The folder is a SMB mount f

[issue18807] Allow venv to create copies, even when symlinks are supported

Roundup Robot added the comment: New changeset ffb01a6c0960 by Vinay Sajip in branch 'default': Closes #18807: pyvenv now takes a --copies argument allowing copies instead of symlinks even where symlinks are available and the default. http://hg.python.org/cpython/rev/ffb01a6c0960 -- nos

[issue18807] Allow venv to create copies, even when symlinks are supported

Changes by Vinay Sajip : -- assignee: -> vinay.sajip versions: +Python 3.4 ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue18807] Allow venv to create copies, even when symlinks are supported

Changes by Antoine Pitrou : -- nosy: +vinay.sajip ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.p

[issue18807] Allow venv to create copies, even when symlinks are supported

New submission from Andrea Corbellini: I'd really appreciate if `venv` could create environments without symlinks. Working on many Python projects, each one with different requirements, I prefer to keep everything I need in a single virtualenv directory, rather than two (one for the virtualenv