Repository navigation
unix: can't import frozen modules from a script that was executed from a file #2322
Description
The unix port can import frozen modules (str and mpy) from the REPL but it can't import them when executing a file (eg from ./micropython test.py). This is because when a file is executed from the command line the first entry in sys.path (which is originally the empty string '') is replaced by the base path of the executing file. This is the correct (CPython) behaviour.
But it means that frozen modules can no longer be found in the path -- they require the empty string in the path in order for them to be found in the import search (note that bare-metal ports always have '' in the path so they are ok).
Some ways to fix:
- Add a hack to the import machinery to always search frozen modules.
- Add a special directory to sys.path (eg
:frozen:/) and prefix all the filenames in the list of frozen files with this special directory. The benefit of this is that it would allow the user to control the order of search when looking for frozen modules.
Activity
pfalcon commentedon Aug 15, 2016
I don't think I like # 2. Too much adhoc magic, which likely will interfere with resource (non-executable) file access.
dpgeorge commentedon Aug 15, 2016
Note that frozen bytecode (frozen mpy files) can't really be exposed as a read-only file (unlike frozen strings), so they'd anyway need to live in a separate "virtual" filesystem to any frozen resource files.
pfalcon commentedon Feb 6, 2017
I'm now being hit by this and eager to fix this ;-).
pfalcon commentedon Feb 6, 2017
So, I can see following way: if sys.path[0] != "", search before it only frozen modules. That at least should give the same search order as for REPL. But what did we decide on overridability of frozen modules? Actually, need to check what CPython does wrt to frozen modules search order and overridability.
pfalcon commentedon Feb 6, 2017
The current workaround is to specify empty path component via MICROPYPATH (de48a27 fixes a case when there're multiple path components, first empty).
dpgeorge commentedon Feb 7, 2017
I think it's useful and important to be able to control the order (and whether they are even searched) of import of frozen modules. Controlling that via sys.path seems the most obvious way.
pfalcon commentedon Apr 30, 2017
It now seems that behavior is different from str vs mpy frozen modules (which is probably rooted in the fact that we have inconsistent, duplicated code to look up each type).
pfalcon commentedon Apr 30, 2017
Ok, now frozen mpy's don't seem to work even from repl.
pfalcon commentedon Apr 30, 2017
Ok, that's because frozen mpy is disable for unix port.
pfalcon commentedon Apr 30, 2017
...or not
pfalcon commentedon Apr 30, 2017
Ok, something just glitches in make apparently.
belyalov commentedon Mar 21, 2018
Any updates on this?
It looks to be still broken:
Having a build of micropython with unittests module frozen:
Simple script
Doesn't work:
all: Move frozen modules to virtual directory.
all: Move frozen modules to virtual directory.
unix/main: Insert script base dir into sys.path rather than replace.
py: Only search frozen modules when '.frozen' is found in sys.path.
dpgeorge commentedon Dec 17, 2021
Fixed by e0bf461
unix/main: Insert script base dir into sys.path rather than replace.
py: Only search frozen modules when '.frozen' is found in sys.path.
py: Only search frozen modules when '.frozen' is found in sys.path.
py: Only search frozen modules when '.frozen' is found in sys.path.