[Python-Dev] pkgutil, pkg_resource and Python 3.0 name space packages

[Phillip J. Eby]

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
>easy_install/setuptools nicer to have this.

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