Question about overriding frozen source modules #1804
Description
When you build a firmware image that has some frozen module (say foo), and you provide a foo.py on the local filesystem, import foo still imports the internal one.
Normally you can control whether your module or a system module gets imported by manipulating sys.path, but for frozen modules there doesn't seem to be any choice.
The best I've come up with so far is to have the file be called foo2 and do import foo2 as foo. Then since foo is already loaded further imports of foo will just return that.
So I was just looking to find out if having the frozen foo.py take precedence was the intention or not.
Activity
pfalcon commentedon Jan 28, 2016
Not really. It was done "for efficiency" (not hit disk I/O if it can be found internally). I agree that overriding usecase makes sense. Well, I guess ideal solution is to make order configurable.
sarusso commentedon Nov 28, 2016
Any news on this? In my case using a different name for the module I want to "override" is really not an option.. @pfalcon could you point me to the source code file/lines where the "not hit disk I/O if it can be found internally" decision is made?
dpgeorge commentedon Nov 29, 2016
There has been no progress on this. If you want to have a go, you'll need to swap the order of lookup in py/builtinimport.c:mp_import_stat_any, and then the order of import in the do_load function in the same file.
Merge pull request micropython#1804 from ITACAInnovation/master
py: Only search frozen modules when '.frozen' is found in sys.path.
dpgeorge commentedon Dec 17, 2021
The order is now configurable by using
.frozen, see 86ce442py: 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.