[Python-Dev] Virtual Python (was Re: Python and the Linux Standard Base (LSB)) (original) (raw)

Mike Orr sluggoster at gmail.com
Mon Dec 4 20:38:20 CET 2006

This may be a bit too FAQ-ish for some people but I'll post it in case anybody benefits from the answer.

On 11/30/06, Phillip J. Eby <pje at telecommunity.com> wrote:

At 02:46 PM 11/30/2006 -0800, Mike Orr wrote: >Speaking of Virtual Python [1], I've heard some people recommending it >as a general solution to the "this library breaks that other >application" problem and "this app needs a different version of X >library than that other app does".

It was actually created to help people who don't have root access (e.g. in shared web hosting accounts) get their "own" Python. It does work for other things, but I haven't been especially recommending it for anything besides that, since eggs take care of multi-version app/library support quite nicely. Indeeed, the virtual-python approach is itself unnecessary now, as easyinstall has much better PYTHONPATH support now, than when virtual-python was created.

What does this last part mean? Virtual Python is still one of the four recommended ways to set up a custom install location in the EasyInstall docs. http://peak.telecommunity.com/DevCenter/EasyInstall#custom-installation-locations

The other approaches work fine for giving each user a private install dir, but don't address the case of the same user wanting different install dirs for different projects. For instance, when exploring Pylons or TurboGears which install a lot of packages I may not otherwise want, I create a Virtual Python for each of them. If I'm developing an application under Virtual Python, I can see at a glance which packages my project needs installed. I can't think of any other way except Virtual Python to do this.

Another point. Setuptools seems to have Two Ways To Do Things regarding package activiation. easy_install puts the latest-installed egg version in its .pth file so it's automatically available via a naive "import". This happens to clutters sys.path with a more entries than some people desire. Meanwhile, programs can use pkg_resources to activate a package or version that may not already be in sys.path. Is this the Way Of The Future? Should people start using pkg_resources for all packages they import? (That would also allow one to remove little-used packages from easy-install.pth.)

Finally, one can use ~/.pydistutils.cfg to specify an install location, but that again allows only one location per user. And in the case of root, it can't distinguish between manually-installed packages and OS-installed packages, which the admin might want in different directories (/usr/local/lib/python vs /usr/lib/pythonVERSION). This hasn't been an issue because OSes haven't been using easy_install or eggs, but it will be when they start doing so.

Do the PYTHONPATH improvements make it possible to just put a directory on your PYTHONPATH and have Python process .pth files in it without using the site.addsitedir() hack? That would probably be my biggest wishlist item.

-- Mike Orr <sluggoster at gmail.com>

More information about the Python-Dev mailing list