[Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages (original) (raw)

Phillip J. Eby pje at telecommunity.com
Mon Jan 7 17:37:19 CET 2008

At 11:24 AM 1/7/2008 -0500, Barry Warsaw wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Jan 7, 2008, at 10:12 AM, Guido van Rossum wrote: > On Jan 7, 2008 6:32 AM, Barry Warsaw <barry at python.org> wrote: >> On Jan 7, 2008, at 9:01 AM, M.-A. Lemburg wrote: >>> We could easily resolve that issue, if we add a per-user site- >>> packages >>> dir to sys.path in site.py (this is already done for Macs). >> >> +1. I've advocated that for years. > > I'm not sure what this buys given that you can do this using > PYTHONPATH anyway, but because of that I also can't be against it. +0 > from me. Patches for 2.6 gratefully accepted. I think it's PEP-worthy too, just so that the semantics get nailed down. Here's a strawman proto-quasi-pre-PEP. Python automatically adds ~/.python/site-packages to sys.path; this is added /before/ the system site-packages file. An open question is whether it needs to go at the front of the list. It should definitely be searched before the system site-packages.

What about including the Python version in the directory name? C Extensions may not work correctly across versions, and bytecode will get recompiled a lot if you're using multiple versions. Also, if this is a 2.6/3.0 change, it's likely that the source won't be compatible across versions either. :)

Python treats ~/.python/site-packages the same as the system site- packages, w.r.t. .pth files, etc.

Open question: should we add yet another environment variable to control this? It's pretty typical for apps to expose such a thing so that the base directory (e.g. ~/.python) can be moved. I think that's all that's needed. It would make playing with easyinstall/setuptools nicer to have this.

Assuming that this is a true "site" directory (i.e., .pth files are recognized), then yes.

More information about the Python-Dev mailing list