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.