virtualenv wheel's entry-point script is version specific to the python its built with

[Ivoz]

Instead, it should be version specific to the python it's installed with. Possible solutions:

• just remove the version-specific script all together
• build separate wheels for every supported python version (with that version of python) so this is never encountered
• Find some other way to create version specific scripts with wheels
• Stop providing wheels for virtualenv

i.e,

C:\Users\Ivo>pip -V
pip 1.5.4 from C:\Python33\lib\site-packages (python 3.3)

C:\Users\Ivo>pip install virtualenv
Downloading/unpacking virtualenv
Installing collected packages: virtualenv
Successfully installed virtualenv
Cleaning up...

C:\Users\Ivo>virtualenv-2.7
You must provide a DEST_DIR
Usage: virtualenv-2.7 [OPTIONS] DEST_DIR

...

And C:\Python33\Scripts\virtualenv-2.7.exe exists. It should be virtualenv-3.3.exe, or just remove it.

From https://github.com/pypa/virtualenv/blob/develop/setup.py#L12

[pfmoore]

Confirmed. From conversation in IRC, this is a bug in virtualenv's setup.py which generates a console entry point with the version of Python used at build time embedded.

Short term fix is to remove that entry point altogether. Longer term, if a versioned command is required, will need a means of capturing that in metadata.

[pfmoore]

Sorry, I confused 2 different issues. You already enumerated the solutions.

My vote is to remove the versioned entry point now, and bring the question of versioned entry points up on distutils-sig, as I think it's a wider issue that affects far more than just virtualenv.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Just add a comment if you want to keep it open. Thank you for your contributions.