site module musings
The site package reads .pth files and inserts directories listed there in sys.path. However it only scans lib directories (lib/python2.4/site-packages/ and lib/python/site-python/ on UNIX) starting with sys.prefix or sys.exec_prefix for these .pth files. Thus if you install a module distribution using the .pth mechanism but passing --prefix=/foo or --home=/bar to setup.py you're in trouble.
Is it such a weird idea to at least scan the directories given in $PYTHONPATH for .pth files? I would even suggest that site just scans the entire sys.path for .pth files, but it might be that I'm overlooking a security issue there (but having an insecure direcotry on sys.path is dangerous anyway and should not happen afaik). I can agree that scanning for a .pth file inside a directory added by a .pth file is rather useless though.
So this leaves me with the idea of filing a bug to change site to scan $PYTHONPATH directories too... If no one stops me I might do that soon.
2 comments:
Simon Percivall said...
One thing you can do meanwhile is to have a sitecustomize.py file where you do a site.addsitedir(dir:str) for each dir in $PYTHONPATH, if you want the functionality without hacking site.py
PJE said...
Guido has previously explicitly rejected .pth processing for PYTHONPATH directories, so a bug report is unlikely to get far.
Installing setuptools (or a setuptools-based package) on a PYTHONPATH directory, however, installs a workaround version of site.py that fixes the issue.
New comments are not allowed.