Description
Dear @dpgeorge, @pfalcon and all maintainers of good faith in MicroPython tooling,
first things first: Thank you so much for your amazing work on MicroPython and its ecosystem - you know who you are.
Our story is that we are developing a datalogger software based on MicroPython called Terkin Datalogger - data logging for humans. It is currently living and growing at [1] and we are now into taking the next level of going from development into production by starting to freeze external modules using mpy-cross.
While having started with mpy-cross-multi.py for a few minutes already, we just have been able to find mpy_cross_all.py through #3040 after taking a second look. Thanks @pfalcon!
The main and essential difference between both programs is currently that we are building upon the fine mpy-cross Python package which is a distribution for the mpy-cross tool you might know already. On the other hand, mpy_cross_all.py calls the mpy-cross binary directly, essentially expecting it to live somewhere on the search path defined by the $PATH environment variable. On one of our macOS workstations, this would yield a mpy-cross suitable for MicroPython 1.10 through Homebrew - however we would like to control the version of mpy-cross used for bytecode compilation more directly.
We would like to improve that situation with mpy_cross_all.py directly, so we are humbly asking about the policies which might apply when hacking on the sidecar tooling of MicroPython itself: Should tools like these be compatible with MicroPython for Unix itself or is it fine to run them on a regular CPython so it would be acceptable to make them compatible with CPython2/3?
We are asking this to adjust for how to build appropriate patches for the MicroPython toolchain.
Thanks in advance for your efforts looking into this and keep up the spirit.
With kind regards,
Andreas.
P.S.: In the line of #4917 and #3034 we are very interested in improving our development workflow in general and will be happy to look into the new things you recently added there.
To keep track of what's around in general, we started some documentation at [2-4] the other day and just recently have been able to add MicroTerkin Agent into the mix, which is a more highlevel utility specifically designed for plug & play operation of networked devices.
Disclaimer: While we are currently stuck on Pycom MicroPython 1.9.4, we will be happy to grow beyond that in the future, just recently ordered our first batch of Pyboard-D's and look forward to be able to use the recently released Vanilla MicroPython 1.11 on it.
P.P.S.: In case someone reading this might be interested, our current toolchain is mainly based on rshell and is implemented by a bunch of Makefiles, see also Makefile, micropython.mk and pycom.mk. Thanks, @dhylands!
[1] https://github.com/hiveeyes/hiveeyes-micropython-firmware
[2] https://community.hiveeyes.org/t/micropython-tooling/2390
[3] https://community.hiveeyes.org/t/running-rshell-natively-on-windows/1774
[4] https://github.com/micropython/micropython/tree/master/ports/nrf#bluetooth-le-repl