A
ago
Dear all,
I was reading pep 370, "Per user site-packages directory"
http://www.python.org/dev/peps/pep-0370/, 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
[install]).
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 site.py 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.
Ago
I was reading pep 370, "Per user site-packages directory"
http://www.python.org/dev/peps/pep-0370/, 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
[install]).
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 site.py 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.
Ago