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