virtualenv-2.7 no longer exists

[Bekt]

Hi, before pip install virtualenv used to create virtualenv and virtualenv-2.7 executables. But today, I noticed the pip command creates virtualenv and virtualenv-3.4. What is the reason for this, and how can I get virtualenv-2.7?

My environment:

$ ls /usr/local/bin/virtualenv*
/usr/local/bin/virtualenv     /usr/local/bin/virtualenv-3.4
$ virtualenv --version
12.0.4
$ pip --version
pip 6.0.3 from /Library/Python/2.7/site-packages (python 2.7)
$ python --version
Python 2.7.5

[pfmoore]

The virtualenv-X.Y entry point comes from the wheel, and X.Y is based on the Python version used to create the wheel, not the Python version it's installed under. Probably the virtualenv wheel was built using Python 3.4 this time. This is not ideal, but it's the current state of affairs, unfortunately. You can either use the non-versioned entry point, or if you want, rename the wrapper (but if you do so, be aware that pip uninstall or pip install --upgrade won't remove it later).

Longer term, I think there's been some talk of supporting versioned entry points in the metadata, but it's not implemented yet, sorry.

[dstufft]

Probably we should just drop the versioned entry points from virtualenv all together. I don't think it really makes sense here. You dont need to use virtualenv-2.7 and virtualenv-3.4 etc in order to select which Python you're creating a virtual environment for since the -p flag exists for that purpose.

[pfmoore]

I'd be +1 on that.

[Bekt]

I agree I can use the -p flag, but it is just a little inconvenient since I had a script that relied on virtualenv-2.7 and others were using it. It is not always easy to get people to upgrade.

[glarrain]

The disappearance of virtualenv-3.4 bit me. It probably should have been documented as a backwards incompatible change so people knew that they should check whether to make changes to their code (for example deployment scripts).

[dstufft]

Fixed (by removal) in #852