8000 Slightly improving the toolchain · Issue #4955 · micropython/micropython · GitHub
[go: up one dir, main page]
Skip to content

Slightly improving the toolchain #4955

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
amotl opened this issue Jul 28, 2019 · 2 comments
Closed

Slightly improving the toolchain #4955

amotl opened this issue Jul 28, 2019 · 2 comments

Comments

@amotl
Copy link
Contributor
amotl commented Jul 28, 2019 •
edited
Loading

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
This was referenced Jul 28, 2019
Closed
Closed
@stinos
Copy link
Contributor
stinos commented Aug 1, 2019

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?

This depends on the tool: some of them are written for both, some for MicroPython, others for CPython (or anything which implements the Python standard), and often CPython3. Some of the latter might also work with the unix port, eventually after installing needed modules from micropython-lib. And some of the former might also work with CPython if you use pfalcon's compatibility layer (don't remember the name).

Anyway, you can usually tell what a tool is primarily meant for by looking at the beginning of the file:

  • if it has a shebang like #!/usr/bin/env python3 then it's meant for CPython
  • if it has u imports like import ure it's for MicroPython
  • if it has imports like subprocess it's CPython since MicroPython does not have that module
  • if it has try/catch blocks trying to import u modules and falling back to the CPython cunterparts, or vice-versa, it's meant for both.

@amotl amotl mentioned this issue Mar 23, 2020
Closed
@jonnor
Copy link
Contributor
jonnor commented Jul 30, 2023

It seems the questions were answered. Proposing to close this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@jonnor @mattytrentini @amotl @stinos
0