Generalizing PEP 370 (per user site-packages directory) via .pth files

ago agostino.russo at
Wed Mar 19 15:38:18 CET 2008

Dear all,

I was reading pep 370, "Per user site-packages directory", and was wondering if the
concept couldn't be generalized by having ways to pass a .pth file as
commandline argument and/or via an environment variable (PYTHONPATH
could also be used to feed .pth files) and/or via special named files
such as ~/.python2.6-user.pth or ./python2.6-local.pth, or possibly
even reusing the paths in the distutils configuration files (under

Any path in the above files would be added to sys.path and scanned
recursively for other pth files.  The system would also load
default.pth from a pre-defined location (e.g. /etc/python2.6/
default.pth), which would point to the default site-packages
directory. There should also be a mechanism to disable/override
default.pth for situations where a clean environment is desired.

This would make it easier to setup special testing environments,
perform local installations, and allow for file-based deployments (in
simple scenarios), without resorting to special tools such as virtual-
python, editing and/or requiring sysadmin intervention. It
would be particularly useful in environments where there is a clear
separation between IT and developer roles.

I just started giving some thoughts to the concept and I am not fully
aware of the implications and requirements of the proposal, but even
if the above turns out to be impractical, I hope that a debate on the
topic will be beneficial.


More information about the Python-list mailing list