I would like to propose adding support for preloading a Python script before executing a Python application.


Potential design:

A new environment variable (e.g. PY_PRELOAD, an allusion to LD_PRELOAD, or PYTHONPRELOAD to be more aligned with the naming pattern of existing variables) is used to specify the path of the script to execute. The script is then executed just before the import of the site module. This is similar to what PYTHONSTARTUP does, except that it works in all cases, not just when launching the REPL.


Rationale:

There are examples of tools that require performing some operations (e.g. monkey-patching) before starting the actual Python application. Currently, this could be achieved in the following rather contrived way:

- prepare an ad-hoc sitecustomize.py file
- add its path to PYTHONPATH
- run the Python application with the computed PYTHONPATH

The ad-hoc sitecustomize.py requires the following steps

- run the custom initialisation code
- remove the path of the custom sitecustomize.py script from sys.path
- unload the sitecustomize module
- try importing sitecustomize to force-load any original sitecustomize scripts that would have run otherwise

The new environment variable makes the whole process a lot easier by allowing tools to just set a single environment variable to achieve the same result.

Can you accomplish what you want with .pth files?

There is also https://www.python.org/dev/peps/pep-0648/

@christian.heimes thanks for bringing PEP 648 to my attention. The solution proposed there would work for me, although it actually does a bit more with some extra complexity. Not a big issue though.

@eric.smith I think that, as argued in PEP 648, pth files are not meant to be used to inject arbitrary code. Besides, the way to exploit pth files wouldn't be much more different than what I described in the issue body.

We generally prefer to have only way way to accomplish a goal. If PEP 648 gets accepted then your proposal won't be accepted. In case the PEP is rejected, then your proposal may still be rejected or may require a new PEP. Preloading has some complicated edge cases, e.g. how it behaves in regards of import errors, subinterpreters, various security flags and startup options.

That's totally fine. My aim is to have something in place that would make preloading some code less clunky than what it is just now.