How to open a sub process with PyInstaller python exe virtual environment?

[EmElleE]

I am looking to try and create a subprocess from mainBundled.exe and the subprocess is either a script.py or a scriptBundled.exe

Have it execute using the self-contained virtual environment of mainBundled.exe is this possible?

1. I know you need the path to the virtual environment or whatever python environment that is self-contained by the py installer? for mainBundled.exe

I am not sure how I would get that, it is the first argument of the array.
Then I know you need the path to the bundledscript.exe or the mainBundled.exe

import os
 subprocess.Popen(["path to bundled? or virtual environment? - python.exe","path to the   .exe relative to the"])

I guess worst case I can just have each subprocess have its own environment if this is not possible.

[rokm]

PyInstaller uses embedded python interpreter to run the frozen entry-point script and collected python modules. So there's no external python.exe interpreter involved, and there's no externally accessible virtual environment left, either (python modules are byte-compiled and collected into executable-embedded archive, while shared libraries and data files are collected into subdirectories of dist directory). So the frozen bundle is (or should be, at least...) self-contained.

If you want to re-use the mainBundled.exe as your python interpreter for running arbitrary external .py scripts, you'll need to implement the redispatch logic based on for example command-line switches. This would allow you to run script.py using a secondary instance of mainBundled.exe, provided that all packages and modules that script.py requires were installed within main environment (and, since script.py does not undergo PyInstaller analysis, you might need to add those packages and modules to hiddenimports if main.py makes no use of them). For an example of such redispatch via sys.executable, see #5978, which had a similar question (that one is Qt/QProcess-based, but subprocess.Popen should follow the same logic).

You could also call external python interpreter that is installed on the target machine. But if you want to deal with virtual environments, you'll probably have to set up environment variables in same way as the activate script does. But that means that you'll target machine will need to have both python and the virtual environment set up, and at that point, you might as well be running the whole program from source.

If you freeze script.py into scriptBundled.exe, you can execute it directly via subprocess.Popen. In that case, it will contain its own copy of the required modules, packages, and other resources. If script.py and main.py share virtual environment, you can also re-utilize shared libraries and data files by building via .spec file that builds two executables in a single dist directory (i.e., use single COLLECT()). That applies to onedir builds; for onefile ones, resource sharing could be achieved by using MERGE() in the .spec file (but then the secondary executable depends on the primary one, because all resources are collected into that one).

[EmElleE]

If you freeze script.py into scriptBundled.exe, you can execute it directly via subprocess.Popen. In that case, it will contain its own copy of the required modules, packages, and other resources. If script.py and main.py share virtual environment, you can also re-utilize shared libraries and data files by building via .spec file that builds two executables in a single dist directory (i.e., use single COLLECT()). That applies to onedir builds; for onefile ones, resource sharing could be achieved by using MERGE() in the .spec file (but then the secondary executable depends on the primary one, because all resources are collected into that one).

Thanks for the detailed answer, I went with the scriptBundled.exe strategy it was a lot easier to do then the other pathways.