[Feature] Make builtin main importable

[laurensvalk]

Is your feature request related to a problem? Please describe.
Not a problem, but exploring some ideas for technical feasibility.

While we might not be able to support multi-file projects on the smaller hubs, here's an idea that could achieve some of the associated use cases.

Describe the solution you'd like
In short, it would imply making this work:

import main

# Imports / runs the stored .mpy file

from main import MyRobotClass

# Imports MyRobotClass from stored .mpy file, so a script being download-and-run can use it.

And we could rename main to something more descriptive.

This would be even more useful if MicroPython is able to run .mpy files without copying them to RAM first. I think this has been mentioned upstream a few times, but I don't know if it is being considered currently.

[dlech]

I think this is as simple as implementing mp_import_stat() and mp_builtin_open() in main.c.

EDIT: probably mp_reader_new_file() rather than mp_builtin_open().

[dlech]

I think this is as simple as implementing mp_import_stat() and mp_builtin_open() in main.c.

This requires enabling MICROPY_ENABLE_EXTERNAL_IMPORT at a cost of about 1KB of flash memory.

[dlech]

And we could rename main to something more descriptive.

This file is already called main.py in the firmware zip file, so I don't think we should rename it.

[dlech]

This would be even more useful if MicroPython is able to run .mpy files without copying them to RAM first.

I'm not sure what you mean here. Do you mean the memory used for allocating objects as the .mpy file is imported? The .mpy is never copied verbatim to RAM.

[dlech]

This file is already called main.py in the firmware zip file, so I don't think we should rename it.

It is a bit confusing though that we currently also call the download and run program main.py.

[dlech]

Using the frozen mpy feature might also be a possibility instead of external imports.

[laurensvalk]

And we could rename main to something more descriptive.

This file is already called main.py in the firmware zip file, so I don't think we should rename it.

It is a bit confusing though that we currently also call the download and run program main.py.

Indeed, hence the suggestion to consider changing it.

Before we pick something, we could consider what it will be called on SPIKE, and what projects/imports will look like on SPIKE. Then the simpler hubs could perhaps be a strict subset instead of something different entirely. This would be easier to explain and document.

[dlech]

Since we are considering a multi-file or at least local file interface in Pybricks Code, I think it makes sense to change the name of the download and run file (eventually this will be a name chosen by the user) and keep main.py as the file included in the firmware image/the file that starts when you press the hub button. Until SPIKE/RI gets file system support, it can work the same as other hubs. When it does get file system support, the the user interface will be different (e.g. slots instead of single file), so it will require a separate explanation anyway. The default slot could look for main.py/main.mpy/main/__init__.py/etc. in the file system to keep the smaller hubs as a strict subset of the slots.

Another alternative would be to all the ability to give an arbitrary file name instead of main.py in the firmware zip file (i.e. add a file name key/value in the metadata dictionary). I suppose this also makes sense considering that this file can be a user-defined file with (eventually in Pybricks Code) a user-defined file name. This alternative is a bit more work to implement, but not too bad.

[laurensvalk]

This would be even more useful if MicroPython is able to run .mpy files without copying them to RAM first.

I'm not sure what you mean here. Do you mean the memory used for allocating objects as the .mpy file is imported? The .mpy is never copied verbatim to RAM.

I meant this.

Using the frozen mpy feature might also be a possibility instead of external imports.

This would potentially allow for an even bigger builtin script, right? That's pretty cool. Does this require running GCC in Pybricks Code? 😄

[dlech]

Does this require running GCC in Pybricks Code?

Hmm... didn't think about that part. Maybe not a possibility then.

[dlech]

Basic fix is committed. Are they any other actionable tasks here?