In response to all of your responses:
No need to take offense, I was merely summarising the research you posted in a way that looks more like scenarios or requirements. It's a typical software engineering task. Being able to collect snippets and let people draw their own conclusions is one thing, but those of us (including yourself) who are actively working in this area are totally allowed to present our analysis as well.
Given the raw material, the summary, and the recommendations, anyone else can do the same analysis and join the discussion, and that's what we're doing. But you can't simply present raw material and assume that people will naturally end up at the same conclusion - that's how you end up with overly simplistic plans where everyone "agrees" because they projected their own opinions into it, then are surprised when it turns out that other people had different opinions.
Cheers, Steve
On 13May2019 1452, Victor Stinner wrote:
)Le lun. 13 mai 2019 à 18:28, Steve Dower steve.dower@python.org a écrit :
My take:
- all the examples are trying to be isolated from the system Python
install (except Vim?)
"Isolation" means different things:
- ignore configuration files
- ignore environment variables
- custom path configuration (sys.path, sys.executable, etc.)
It seems like the most common need is to have a custom path configuration.
Py_IsolatedFlag isn't used. Only py2app manually ignores a few environment variables.
- all the examples want to import some of their own modules before
running user code
Well, running code between Py_Initialize() and running the final Python code is not new, and my PEP doesn't change anything here: it's still possible, as it was previously. You can use PyRun_SimpleFile() after Py_Initialize() for example.
Maybe I misunderstood your point.
- nobody understands how to configure embedded Python :)
Well, that's the problem I'm trying to solve by designing an homogeneous API, rather than scattered global configuration variables, environment variables, function calls, etc.
Also from my own work with/on other projects:
- embedders need to integrate native thread management with Python threads
Sorry, I see the relationship with the initialization.
- embedders want to use their own files/libraries
That's the path configuration, no?
- embedders want to totally override getpath, not augment/configure it
On Python 3.7, Py_SetPath() is the closest thing to configure path configuration. But I don't see how to override sys.executable (Py_GetProgramFullPath), sys.prefix, sys.exec_prefix, nor (internal) dll_path.
In the examples that I found, SetProgramName(), SetPythonHome() and Py_SetPath() are called.
My PEP 587 allows to completely ignore getpath.c/getpath.c easily by setting explicitly:
- use_module_search_path, module_search_paths
- executable
- prefix
- exec_prefix
- dll_path (Windows only)
If you set these fields, you fully control where Python looks for modules. Extract of the C code:
/* Do we need to calculate the path? */ if (!config->use_module_search_paths || (config->executable == NULL) || (config->prefix == NULL)#ifdef MS_WINDOWS || (config->dll_path == NULL) #endif || (config->exec_prefix == NULL)) { _PyInitError err = _PyCoreConfig_CalculatePathConfig(config); if (_Py_INIT_FAILED(err)) { return err; } }
OpenOffice doesn't bother with complex code, it just appends a path to PYTHONPATH:
setenv("PYTHONPATH", getenv("PYTHONPATH") + ":" + path_bootstrap);It can use PyWideStringList_Append(&config.module_search_paths, path_bootstrap), as shown in one example of my PEP.
Victor
Night gathers, and now my watch begins. It shall not end until my death.