mpy-tool does not properly collect module names for imports
Consider an application that has the following module file:
foo/bar/quux.py
Put an import statement in some other file:
from foo.bar import quux
When freezing the module with mpy-tool.py, the names foo.bar and quux are collected. However:
foo.bar.quuxis not collected, which will be created as a qstr at runtime, becausesys.modulesuses it as a key- neither
foonorbaris collected.barwill be created as a qstr at runtime, because the dict offooneeds to insert it as a key
Of course, if we use relative imports, there's a similar problem: in foo/bar/baz.py, from . import quux should (but can't really know to) also collect foo.bar.quux despite the string not existing anywhere in the file.
I'm not sure if this is something to solve in mpy-tool itself, or whether there should be a separate step that collects symbols in this way. But it seems that using file names to generate both the fully qualified module name and the individual components would be the right thing to do. (that is basically the workaround i'm using: generate all_modules.py that walk the filesystem and convert every py file name to import that.file.name, which collects "that.file.name", and that.file.name which collects "that"", "file" and "name")
Question about overriding frozen source modules
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.