Virtual Python (was Re: Python and the Linux Standard Base (LSB))
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
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-loca...
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
participants (1)
-
Mike Orr