Make the startup behavior more explicit

[deshipu]

Right now the behavior of CircuitPython at startup has a lot of details that are hidden, and have to be learned by reading tutorials, rather than by exploration: what files are run on startup, where to put USB-initializing code, etc. We could make it more visible by putting most of the initialization functions in a boot.py file created from a template on board startup whenever it is missing. Then people can simply look inside to see what is happening, experiment with modifying the contents, and if they break something — delete or rename the file, so that a default can be re-created.

We could also use #184 to allow users to control what file is being run on startup, and possibly also control some options about how it is supposed to be run.

[cefn]

I have a use case which may be relevant to this, depending on the breadth of functionality in a boot.py explicitly-coded python supervisor.

If the python-implemented supervisor was explicit in boot.py and oversaw the policy decision of dropping the VM after main.py and giving a fresh VM to the REPL, tweaking boot.py would enable alternative VM management strategies to be employed. Importantly no circuitpython-compatible fork would be needed to achieve this, since it happens in 'userspace' just by tweaking boot.py.

Use case - educators preparing projects

In my use case, I would like to be able to pre-populate a VM with a set of symbols which are immediately available for interactive invocation and investigation (tab-completion) from a newly loaded REPL (without having to explain python imports and without the learner having to type an accurate import before their first line of code).

In the use case, the symbols in this VM can be accessed via wired REPL (e.g. Gnu Screen) or via WebREPL hence presenting whatever python 'vocabulary' is wished by the educator (who is preparing a programmable project wired to some inputs/outputs).

The demo in https://vgkits.org/blog/2018/05/08/introductory-video-tutorial/ indicates the use case as demonstrated through micropython.

Alternate approach

Entering the REPL using an explicit blocking function call made from within the VM (e.g. as a call made within main.py) could be an alternate approach to allow various policies to be achieved. This would allow soft-exiting main.py to continue to be hard-coded as per circuitpython-normal, dropping the VM. It's just that the REPL was explicitly invoked from within the initial VM. For example you could create a main.py tutorial sequence within a continuous VM like...

from fancy import repl, reset
prepare_step_1()
repl(globals())
prepare_step_2()
repl(globals())
prepare_step_3()
repl(globals())
report_progress()
reset()