Virtualenv

Dealing with multiple versions of Python with Virtualenv

Asked by Noah Gift

OS X Leopard users have a plethora of problems with Python. Do you use the system python which has DTrace compiled in? How do you install a version other than python 2.5.1. While these problems don't have quick and easy fixes, it is a fact, that OS X users are going to need multiple versions of Python. It is also a fact, that every OS is going to have multiple versions of Python, as 2.6, and Python 3000 comes out. How does virtualenv plan on keeping each specific version of python straight? It seems likely I am going to have python 2.4.3, python 2.5.1, python 2.6, and python 3000.

Should virtualenv support a:

virtualenv --python=2.6 ENV

It seems much easer than have 4 different versions of virtual env all aliased in my ~/.zshevn

Question information

Language:
English Edit question
Status:
Answered
For:
Virtualenv Edit question
Assignee:
No assignee Edit question
Last query:
Last reply:

This question was reopened

Revision history for this message
Ian Bicking (ianb) said : 		#1

Whatever python interpreter you use to create the virtualenv, that's the interpreter that will be installed into the new environment. So run 'python2.4 virtualenv.py Py24', 'python2.5 virtualenv.py Py25', '/usr/local/bin/python virtualenv.py DarwinPython', etc.

Revision history for this message
Noah Gift (noah-gift) said : 		#2

I have effectively done this by creating the following aliases:

alias virtualenv-py25="/usr/bin/python2.5 /usr/local/bin/virtualenv.py"
alias virtualenv-py24="/usr/bin/python2.4 /usr/local/bin/virtualenv.py"

I run into a problem though if I install the virtualenv egg as the two version of virtualenv clobber each other, as only one entry point can exist in say /usr/local/bin/

Basically as of know it is not possible to easy_install virtualenv as a result.

Revision history for this message
Ian Bicking (ianb) said : 		#3

Yeah, I suppose it would be nice if stuff got installed as "script-X.Y" (where X.Y is the Python version), in addition to just the script name.

I suppose you could add this in a per-setup.py manner easily enough, just adding entry_points="""[console_scripts] foo-%s = foo.command:main""" % sys.version[:3]

That might be useful for virtualenv at least.

Revision history for this message
Noah Gift (noah-gift) said : 		#4

I am ashamed to admit it, but I still don't understand entry points in practice yet, BUT, we have a talk on it tonight at PyAtl so lets see if can absorb it tonight apply it tonight when I get home. Entry points are pretty cool, but part of it seems like magic. How does a script now where to install itself from OS to OS version?

Revision history for this message
Ian Bicking (ianb) said : 		#5

The entry points here are pretty modest. The [console_scripts] entry point has "script = package.module:object". Which means "create a script named 'script', and when its run call 'object' found in 'package.module'". By dynamically creating the 'script' part of it in setup.py we can append the Python version to the script name.

Can you help with this problem?

Provide an answer of your own, or ask Noah Gift for more information if necessary.

To post a message you must log in.