MicroPython Unix port compatibility

[paravoid]

I'm trying to use the MicroPython Unix port to quickly iterate on changes locally (sometimes with test fixtures etc.) before pushing them to the microcontroller. For that purpose I'd like the code to be as closer as to the one running on the microcontroller, so using MicroPython rather than CPython, and this module, rather than conditionally switching to something like Paho.

That doesn't work out of the box, as far as I can tell for two reasons:

• machine.unique_id not being available on Unix. I reported that upstream to upstream MicroPython (ports/unix: please implement machine.unique_id() micropython/micropython#12216), but it's seemingly going to take a while, and its usage here is trivial enough to just override with some static value?
• All the network integration. Separate network hardware interface from mqtt client #57 seems to be relevant to this, albeit a bit stalled. I've overriden this with some stubs, and a fork by Thorsten von Eicken that I found seems to be doing the same. It'd be nice if this was properly supported, even if somewhat hacky.

CPython compatibility would also be nice, but that feels like a larger endeavor so explicitly keeping it out of scope for this issue.

[peterhinch]

I fully accept the limitations of this library. You might like to read this short doc which provides background and advocates a complete redesign. For this reason I don't plan to implement half-way-house incremental changes (although I fully support the existing code).

For personal reasons I'm not in a position to undertake a full redesign. The MicroPython maintainers have discussed MQTT in the past but I don't know if it's on their roadmap.

[zcattacz]

@paravoid , you can try my fork of mqtt_as.py. It's a stripped down version to work for both micropython-unix and cpython.

[jonnor]

Agreed that good compatibility with Unix port with microcontrollers is very useful, as it enables rapid iteration on the host, and also running automated tests etc on the host (including in CI etc).

There seems to be a solution for the MQTT parts in above comment about mqtt_as. And the machine identifier has a specific issue associated with it. So can we close this issue in favor of more specific ones? As it stands the title is very generic, and I fear it could stay open forever (compatibility is generally a forever thing). Or rename to reflect the scope as being about particular network/MQTT issues?