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

[Phillip J. Eby]

At 11:38 AM 12/4/2006 -0800, Mike Orr wrote:
>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.

Simply install the packages to an arbitrary directory using -m 
(--multi-version), and allow the scripts to be installed to the same 
directory.  When the scripts are run, they'll find their eggs in the script 
directory.  Neither PYTHONPATH manipulation nor virtual Pythons are needed 
to achieve this - it's a self-contained single-application directory.  (It 
will still have to import pkg_resources from a copy of setuptools installed 
somewhere else, e.g. on PYTHONPATH or in site-packages, or someday perhaps 
the stdlib.)


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

Using -m (--multi-version) suppresses this behavior.  The "just works" 
behavior of automatically adding to sys.path is just the default.


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

No.  Setuptools automatically wraps generated scripts with 
pkg_resources-based activation, so there's almost never a need to request 
packages.  So, if you need dynamic access for a project, just create 
yourself a setup.py for it and put the requirements in there.  Then run 
"setup.py develop" to generate wrappers for your scripts.  The wrappers 
will do all the activation for you when they're run.


>Finally, one can use ~/.pydistutils.cfg to specify an install
>location, but that again allows only one location per user.

One *default* location per user... per current directory.  Since it's based 
on distutils, easy_install always reads setup.cfg from the current 
directory, which can set the defaults.  And of course, using -d 
(--install-dir) on the command line lets you specify a one-off target.


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

Yes, it does -- but it only works for packages installed by easy_install; a 
special 'site.py' is added to the directory that adds the necessary hooks 
around the "real" 'site' module's processing.