Description of problem: virtualenv 1.7.2 does not create the python2 and python27 symlinks to python. This causes scripts to be broken after "virtenv --relocatable" is run. Version-Release number of selected component (if applicable): virtualenv 1.7.2 How reproducible: Always Steps to Reproduce: 1. virtualenv --system-site-packages /path/to/virtenv 2. virtualenv --relocatable /path/to/virtenv Actual results: There is no python27 in the virualenv, but scripts refer to it. Expected results: There are two symlinks: python2 -> python python27 -> python Additional info: It appears that this is due to a whitespace error in the code.
Created attachment 784718 [details] python-virtualenv specfile for 1.10.1
Went ahead and built for the latest version, specfile attached.
(In reply to Rob Millner from comment #3) > Went ahead and built for the latest version, specfile attached. With regards to current buggy version. I would assume that there is a workaround in the sense that those symlinks can be created manually after running virtualenv. Correct?
Correct - they can easily be created.
OK, due to existing workaround and GA getting close we'll move this to RHSCL 1.1. Going to clone this bug for release notes so that this is properly documented in the meantime.
Actually had a closer look... Before runnning "virtualenv --relocatable" shebangs look like this: #!/path/to/virtenv/bin/python After running "--relocatable" shebangs get changed to: #!/usr/bin/env python2.7 If you are inside scl-enabled environment the above shebang will correctly run python2.7 from PATH (which will be modified to include /opt/rh/python27/root/usr/bin/). Outside scl python library would not be resolved by linker either way. Even if symlinks are manually created, they are not used by #!/usr/bin/env python2.7 Am I missing something?
The virtual environment has an "activate" script that puts it at the front of PATH, causing python2.7 and python2 to be resolved inside of it.
I have updated source to 1.10.1.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2013-1238.html