[Python-Dev] Virtual Python (was Re: Python and the Linux Standard Base (LSB))
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 , 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
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