Incomplete sys.path with embeddable python (Windows)!?
Ralf M.
Ralf_M at t-online.de
Sat Apr 22 17:35:37 EDT 2023
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.
More information about the Python-list
mailing list