DLT
DLT

Reputation: 441

sys.path not always/reliably set by sitecustomize -- how can it be reliably overridden?

I have an application using embedded Python, which includes python.exe. I have added a sitecustomize.py to set sys.path, something like:

import sys
sys.path = ['.','.\\python310.zip','.\\Lib','.\\Lib\\site-packages']

This works for me and I can see this path when running python.exe. But it does not work for a colleague, their environment shows a different sys.path:

['.','.\\python310.zip']

They're calling the same command from the same installation from the same folder location but on a different host.

I understand there are also ._pth (or .pth) files and pyvenv.cfg that can have an effect on sys.path and a PYTHONPATH environment variable. Then there's PYTHONSTARTUP, usercustomize, PYTHONUSERBASE, sysconfig and nine 'schemes' 🤦.

What are all the bootstrapping options to set sys.path and what takes precedence?

What role does site.py play in this? Do user packages take precedence over site packages and is there another 'global' level above site that overrides everything?

I really want to clobber everything but my own paths based on the installation file layout. How do I define my embedded environment so that it is not affected by settings outside that environment?

Upvotes: 0

Views: 450

Answers (1)

DLT
DLT

Reputation: 441

I found the answer I was looking for at https://docs.python.org/3/library/sys_path_init.html#sys-path-init

It looks like the order of evaluation is

  1. PYTHONPATH environment variable.
  2. sitecustomize.py.
  3. ._pth files.
  4. pyvenv.cfg

My testing shows that even if sitecustomize.py sets an explicit sys.path this can be affected by ._pth files.

The import site statement in _pth will append site-specific paths (e.g. site-packages) to the module search path. This includes evaluating any .pth (without the _) files.

If a pyvenv.cfg file is found, it'll change the environment regardless of the previous configurations.

Upvotes: 0

Related Questions