virtualenv-2.7 no longer exists #692

Closed
Bekt opened this Issue Dec 25, 2014 · 6 comments

Projects

None yet

4 participants

@Bekt
Bekt commented Dec 25, 2014

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
Member
pfmoore commented Dec 25, 2014

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
Member
dstufft commented Dec 25, 2014

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
Member
pfmoore commented Dec 25, 2014

I'd be +1 on that.

@Bekt
Bekt commented Dec 26, 2014

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.

This was referenced Jan 5, 2015
@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
Member
dstufft commented Mar 6, 2016

Fixed (by removal) in #852

@dstufft dstufft closed this Mar 6, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment