1.11.6 creates right shebang but wrong file name

[frumpel]

When installing virtualenv using pip the shebang and file name don't match. Repro:

On CentOS 6.4 install python with altinstall

tar -xf ${version}.tgz --ungzip
cd $version
./configure --prefix=/usr/local --with-zlib
make
#really important to make the altinstall if you want to install python2.7 next to python2.6
make altinstall

Install pip using the specific version of python desired

/usr/local/bin/easy_install-2.6 pip
/usr/local/bin/pip2.6 install virtualenv

The resulting virtualenv entries in /usr/local/bin end up being (note the WRONG version number):

/usr/local/bin/virtualenv
/usr/local/bin/virtualenv-2.7 

At the same time the file contains the (CORRECT) hashbang for the python executable:

#!/usr/local/bin/python2.6

This appears to have been introduced in the transition from 1.11.5 to 1.11.6

[pfmoore]

See https://github.com/pypa/virtualenv/blob/develop/setup.py#L32

This is probably because the virtualenv wheel was built under Python 2.7. See the comment at https://github.com/pypa/pip/blob/develop/pip/wheel.py#L283 which describes the issue - virtualenv should probably not provide a versioned entry point at all.

You can of course just ignore or remove the versioned entry point. Or copy it to a virtualenv-2.6 if you want (but pip uninstall won't remove that). Or if it really matters to you you could force a build from source using --no-use-wheel (but that seems to me like overkill).

[frumpel]

Thank you for finding the root cause of the problem.

This is fairly significant when you consider installing and maintaining multiple versions of python using automation tools like puppet. If all the version installs write the same versioned entry point then the copy approach will fail.

[gaborbernat]

I think this should be fixed, we don't support Python 2.6 anymore but if you can reproduce it with 2.7+ open it again.