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

[Mike Orr]

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
> easy_install 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>