When a non built-in module is imported, the interpreter searches in the locations given by sys.path
. sys.path
is initialized from these locations (http://docs.python.org/library/sys.html#sys.path):
While the first two sources are straight-forward, can anyone explain how the third one works, and what possibilities there are for influencing it?
Although I would be interested in a general solution, my specific issues are:
/Library/Python/2.7/
, which is where superpack installed them, instead of from the enthought site-packages.wxPython
application created with py2app
-A
does not have the same sys.path
as when starting the application with python start_app.py
. The basis of the third source is set at compile time (or configure time, more precisely), depending on the platform. It is then expanded and added to at run-time via .pth
files, etc. (which is something you can do once the Python executable is compiled to influence that third source).
This page of the Python documentation has all the information on how .pth
files work, and also more information on how sys.path
is constructed from build-time settings, etc. http://docs.python.org/library/site.html
I'm not sure why you want to influence that third source specifically though, when you can influence the whole sys.path
. Anyhow, the three ways of influencing sys.path
(without recompiling Python or patching the source code) are:
.pth
files and dropping them where Python scans for packages. (See the link earlier for details.)Programmatically, by importing sys
and then appending or prepending to sys.path
import sys
sys.path.insert(0, '/this/path/will/be/considered/first')
Hopefully one of these three ways should help you do what you want.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With