Publish mpy files on Release creation

[markafarrell]

This PR will automatically compile mpy files for any .py files in src/

The workflow has 3 modes:

1. When a new tag is created matching (v*.*.*), python source files in src/ will be complied for the latest 5 versions of micropython/mpy-cross and a release created for each version of micropython/mpy-cross with the compiled mpy files attached as assets.

Example workflow:

https://github.com/markafarrell/microdot/actions/runs/6211289626

3. Once daily a workflow will run that will iterate over all tags matching v*.*.*, python source files in src/ will be complied for the latest version of micropython/mpy-cross and a release created with the compiled mpy files attached as assets. This will mean that when new version of mpy-cross are released there will also be compiled version of microdot available for people to use.

Example workflow:

https://github.com/markafarrell/microdot/actions/runs/6211317787

3. The workflow can also be run manually and a json list of mpy-cross versions provided as an input. e.g. ["1.19.0", "1.19.1"]. This will result in releases being created for all tags matching v*.*.* compiled for the supplied versions of micropython. This will allow for the ad-hoc creation of compiled versions of microdot for any available version of micro-python.

Example workflow:

https://github.com/markafarrell/microdot/actions/runs/6211299190

This will make it easier for consumers to be able to consume microdot using mip

e.g.

mpremote a0 mip install https://github.com/miguelgrinberg/microdot/releases/download/micropython-1.20-v1.3.3/microdot.mpy

[miguelgrinberg]

The problem with this is that mpy files are versioned and can only be used on the version of MicroPython they were generated from. So these releases will only work with the current version of MicroPython, and are bound to break as soon as a new release comes out and the mpy version is increased.

The MicroPython folks have a solution for this, but the mpy repository they maintain is not open to third party packages, they just use it for the MicroPython standard library. Once and if they decide to allow third parties to upload packages this problem will be resolved, and people will be able to install mpy files directly, and without having to provide custom URL locations.

[miguelgrinberg]

this method of installation is flawed, because mpy files cannot be used across MicroPython versions. When new MicroPython releases are out the mpy files that were archived in the release will not work anymore. Basically you need a set of mpy files for each MicroPython release.

[markafarrell]

Updated to use include the micropython version

[markafarrell]

The problem with this is that mpy files are versioned and can only be used on the version of MicroPython they were generated from. So these releases will only work with the current version of MicroPython, and are bound to break as soon as a new release comes out and the mpy version is increased.

The MicroPython folks have a solution for this, but the mpy repository they maintain is not open to third party packages, they just use it for the MicroPython standard library. Once and if they decide to allow third parties to upload packages this problem will be resolved, and people will be able to install mpy files directly, and without having to provide custom URL locations.

I didn't know this.

I have updated the PR to compile the mpy files for the latest 5 versions of micropython/mpy-cross. And create a release for each set of compiled files.

Feel free to close the PR if you aren't interested in doing this.

[miguelgrinberg]

Are there any other third-party projects implementing this type of solution that you know of?

What I see is that this still does not address the problem that once a new MicroPython release comes out, none of the existing releases of Microdot will have the mpy files for it. As I said above, the MicroPython project needs to figure out a way to support third-party packages, and they haven't done that yet. See micropython/micropython-lib#578 and #67 for context on the discussions that have already happened on this topic.

[markafarrell]

Are there any other third-party projects implementing this type of solution that you know of?

Not that I know of but it doesn't seem like an unresonable way to approach the problem

What I see is that this still does not address the problem that once a new MicroPython release comes out, none of the existing releases of Microdot will have the mpy files for it. As I said above, the MicroPython project needs to figure out a way to support third-party packages, and they haven't done that yet. See micropython/micropython-lib#578 and #67 for context on the discussions that have already happened on this topic.

We could approach this by having a scheduled job that will run regularly, iterate over all tags and compile the mpy files for the latest released mpy-cross.

At this point I'm just using this as an opportunity to play with github actions. Sorry if I'm being annoying.

[miguelgrinberg]

While I continue to wait for MicroPython to release a solution for third-party packages, I have added a section in the documentation on cross-compiling and freezing Microdot.