Incomplete sys.path with embeddable python (Windows)!?

[Ralf M.]

Am 21.04.2023 um 17:31 schrieb Mats Wichmann:
> On 4/20/23 15:47, Ralf M. wrote:
>> Hello,
>>
>> when I run a script with a "normally" installed python, the directory 
>> the script resides in is automatically added as first element to 
>> sys.path, so that "import my_local_module" finds my_local_module.py in 
>> the directory of the script.
>>
>> However, when I run the same script with embeddable python ("Windows 
>> embeddable package (64-bit)", download link
>> https://www.python.org/ftp/python/3.11.3/python-3.11.3-embed-amd64.zip) the script directory is *not* prepended to the path, thus "import my_local_module" gives an ImportError.
> 
> This is intended behavior - the question comes up from time to time. The 
> embeddable distribution is intended to be part of an application, not a 
> general-purpose Python you can call for just anything.
> 
> There are a bunch of details here, for example:
> 
> https://github.com/python/cpython/issues/79022
> 
Thank you for the pointer to the issue. I'll try to remove the ._pth 
completely (and see whether that breaks anything) and may have a look at 
the nuget.org package.

I can see that for many cases the behaviour is appropriate, but I had 
hoped that there is a configuration option for the cases where it is not.

About my use case:
There is a complex application package, consisting of some commercial 
and some freeware software, tied together with scripts in at least four 
different scripting languages. Now I intend to add further functionality 
in a fifth language, Python. The idea is to make the embeddedable 
package part of the application package and have scripts for the new 
functions. Several independent functions are to be added, each 
consisting of a script plus some local modules, and all of them should 
use the same python embedded into the application package.