mpy-tool does not properly collect module names for imports

[matejcik]

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.quux is not collected, which will be created as a qstr at runtime, because sys.modules uses it as a key
• neither foo nor bar is collected. bar will be created as a qstr at runtime, because the dict of foo needs 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")

[dpgeorge]

I did recently notice this same thing, that some parts of some imported names (as described in detail above) will create qstrs at runtime.

One way to improve this situation is to run micropython.qstr_info(1) at the REPL after importing everything, and then include the output list of qstrs in qstrdefsport.h.

[jonnor]

Is this still relevant with recent MicroPython version?