Re: Incomplete sys.path with embeddable python (Windows)!?
On 23/04/23 10:04 am, Ralf M. wrote: I thought about that, but for that to work all local modules across all script locations must have unique names, otherwise import might get hold of a module from the wrong directory. You could put all the local modules belonging to a particular script into a package named after the script, e.g. put the local modules used by foo.py into a package called foolib. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Incomplete sys.path with embeddable python (Windows)!?
On 4/22/2023 5:45 PM, Ralf M. wrote: Am 22.04.2023 um 03:27 schrieb Greg Ewing via Python-list: How are you invoking your script? Presumably you have some code in your embedding application that takes a script path and runs it. Instead of putting the code to update sys.path into every script, the embedding application could do it before running the script. In principle a good idea, but I don't know how to do that: The script is currently invoked by a .cmd file, but that may change to a shortcut (.lnk). This is what the embeddable package documentation calls "Python Application - simple approach". To update sys.path on start up I would need to do something like C:\path\to\python.exe --add-path C:\s-path C:\s-path\script.py but I couldn't find an option like --add-path. You can get the .cmd file's path and put it into an environmental variable (or as a command line argument). If you haven't encountered that trick of Windows batch file procesing, here it is: %~dp0 (returns the directory a batch file is running from) -- https://mail.python.org/mailman/listinfo/python-list
Re: Incomplete sys.path with embeddable python (Windows)!?
Am 21.04.2023 um 18:07 schrieb Thomas Passin: On 4/20/2023 5:47 PM, 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. I couldn't find an option to get the "normal" behaviour. Any ideas how to do that? What I tried so far: [...] * I can add the following lines to every script: import sys script_path = __file__.rsplit("\\", 1)[0] if script_path not in sys.path: sys.path[0:0] = [script_path] import my_local_modul [...] Thank your for your hints. I haven't worked with embeddable python, but here are some possibilities that came to mind, depending on how your system works - 1. If your script is started from the command line, sys.argv[0] gives the path to the script; I didn't think of sys.argv[0] to get at the path; this might be quite useful, I'll try it out next week. You could use os.path.dirname() to get its directory. This will end up the same place as your code fragment, but looks nicer and handles different path separators (e.g., Linux vs Windows); Yes, but it requires another import and the embedded package is only available for windows anyway, I think. I'll consider the idea, though. 2. You could write a little module that figures out the script's path and import that first in all your scripts. 3. If you know all the directories that your scripts will be in, you could add them all to a xx.pth file (do a search to make sure where to put .pth files for an embeddable case). I thought about that, but for that to work all local modules across all script locations must have unique names, otherwise import might get hold of a module from the wrong directory. Certainly doable for a few scripts, but might become a source of hard to track errors when the number of scripts increases and later maintainers are not aware of the naming restriction. [...} -- https://mail.python.org/mailman/listinfo/python-list
Re: Incomplete sys.path with embeddable python (Windows)!?
Am 22.04.2023 um 03:27 schrieb Greg Ewing via Python-list: How are you invoking your script? Presumably you have some code in your embedding application that takes a script path and runs it. Instead of putting the code to update sys.path into every script, the embedding application could do it before running the script. In principle a good idea, but I don't know how to do that: The script is currently invoked by a .cmd file, but that may change to a shortcut (.lnk). This is what the embeddable package documentation calls "Python Application - simple approach". To update sys.path on start up I would need to do something like C:\path\to\python.exe --add-path C:\s-path C:\s-path\script.py but I couldn't find an option like --add-path. -- https://mail.python.org/mailman/listinfo/python-list
Re: Incomplete sys.path with embeddable python (Windows)!?
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. -- https://mail.python.org/mailman/listinfo/python-list