New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

virtualenv-2.7 no longer exists #692

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

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

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore Dec 25, 2014

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Dec 25, 2014

Member

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.

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

This comment has been minimized.

Show comment
Hide comment
@pfmoore

pfmoore Dec 25, 2014

Member

I'd be +1 on that.

Member

pfmoore commented Dec 25, 2014

I'd be +1 on that.

@Bekt

This comment has been minimized.

Show comment
Hide comment
@Bekt

Bekt 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.

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.

@dstufft dstufft referenced this issue Jan 5, 2015

Closed

Rewrite virtualenv #697

0 of 5 tasks complete
@glarrain

This comment has been minimized.

Show comment
Hide comment
@glarrain

glarrain Feb 26, 2016

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).

glarrain commented Feb 26, 2016

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

This comment has been minimized.

Show comment
Hide comment
@dstufft

dstufft Mar 6, 2016

Member

Fixed (by removal) in #852

Member

dstufft commented Mar 6, 2016

Fixed (by removal) in #852

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment