Replies: 1 comment 3 replies
-
On Windows, we import packages in an isolated sub-process prior to running binary dependency analysis ("Looking for dynamic libraries"), in order to catch dynamic changes to DLL search paths that are made by some packages during their initialization. See: pyinstaller/PyInstaller/building/build_main.py Lines 173 to 273 in 3aa87b0 |
Beta Was this translation helpful? Give feedback.
3 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I have a program that when running initializes some config information. This information is only available after runnning the program.
Some other modules of my program use that information and in case some of them tries to use the configuration before it is initialization it throws an exception. I have some modules that use that config just by the fact that they are imported.
We have noticed that during the build process of our ".exe" file the exception is thrown just after Pyinstaller prints "Looking for dynamic libraries".
Despite that exception Pyinstaller goes on and the ".exe" seems to be correctly generated.
But the thing is that this seems to imply that during build time Pyinstaller is in fact "running" the code in my modules, not just analyzing them.
That was unexpected for us and could potentially be an issue depending on the sideeffects this execution could have.
Just in case it matters the package that triggers the exception is imported in a modules "__init__". Maybe is just the __init__ files that Pyinstaller does run?
Are we right to assume that our code will be, at least partially, run also at build time ? Should we organize our code taking this into consideration?
Beta Was this translation helpful? Give feedback.
All reactions