This is essentially a continuation of this old thread.
So, as mentioned in the thread above, I have a setup in which certain modules are not frozen for distribution, as the project’s “base” modules are.
Instead, they’re kept more-or-less as-is, and imported dynamically by the “base” program.
As far as that goes, it seems to work.
However, I’ve now found that such modules don’t seem to be able to import anything from the base, frozen modules–which is a bit of a problem for me.
For example, consider the following hierarchy:
<base-dir>
|
|___ base_script.py
|
|___ some_class.py
|
|___<sub-dir>
|
|___ nonfrozen_class.py
|
|___ __init__.py
There, as the name suggests, “nonfrozen_class.py” is not frozen by setuptools when a distributable is made.
Further, presume that “base_script.py” imports “nonfrozen_class.py”, and further that “nonfrozen_class.py” imports “some_class.py”.
Outside of a frozen, distributable build, the above works.
Within a frozen, distributable build, however, the above crashes when “nonfrozen_class.py” attempts to import “some_class.py”. :/
I’ve attached here a simple test-program that–on my machine at least–demonstrates the issue.
importTester.zip (1.9 KB)
It contains the following files:
- setup.py
- requirements.txt
- core.py
- simpleClass.py
- SubClasses/secondary_dynamic.py
- SubClasses/__init__.py
The main program is “core.py”.
This program dynamically imports from “secondary_dynamic.py”, which in turn (statically) imports from “simpleClass.py”.
If you simply run “core.py”–i.e. without building a frozen version–you should see the following output:
Moggy Instantiated!
A Simple Class Instantiated!
I am a Moggy
The first line is printed by the class in “secondary_dynamic.py” on being instantiated by “core.py”. The second line is then printed by the class in “simpleClass.py” on being instantiated by the class in “secondary_dynamic.py”. And finally, the third line is printed by the class in “secondary_dynamic.py” at a function-call from the core program.
However, if you then attempt to build the program and run it, you should see something like the following:
Traceback (most recent call last):
File "__main__", line 4, in <module>
File "importlib", line 126, in import_module
File "importlib._bootstrap", line 1050, in _gcd_import
File "importlib._bootstrap", line 1027, in _find_and_load
File "importlib._bootstrap", line 1006, in _find_and_load_unlocked
File "importlib._bootstrap", line 688, in _load_unlocked
File "importlib._bootstrap_external", line 883, in exec_module
File "importlib._bootstrap", line 241, in _call_with_frames_removed
File "/home/thaumaturge/Documents/My Game Projects/BugHunt/ImportTester/Frozen/dist/Import Tester-1.0.0_manylinux2014_x86_64/Import Tester/SubClasses/secondary_dynamic.py", line 2, in <module>
from simpleClass import SimpleClass
File "importlib._bootstrap", line 1027, in _find_and_load
File "importlib._bootstrap", line 1004, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'simpleClass'
As you can see, the code seems to get into “secondary_dynamic.py”, as intended–but from there doesn’t seem to be able to get back to the frozen modules.
Does anyone know how I might get this working…?
[edit]
*Bump*
I did have a thought: Might this work better if the dynamically-imported script were itself independently frozen…?
That is, if one had the dynamically-imported script compiled to a library file or some such–still referencing things from the main program, mind you–that could be dropped into place…?
