Micropython fork -- should we change this and how

[bwhitman]

(Ported over from issues)

See tweet :
https://twitter.com/matt_trentini/status/1625732568065904640?s=20

Questions with no answers yet

• what would a non-fork look like? We have multiple ports (macos, esp32s3, soon windows) and a lot of code in extmod/tulip
• how can we keep our changes to the stuff in the REPL (hijacking the UART, basically) in a way that doesn't touch core MP
• how would it impact the build process for non-experts
• prevent against breaking changes in MP APIs / pinned submodules?
• is it worth it? what new features are we missing now since our freeze of MP back in may 2022

[bwhitman]

I think a good first step is to get latest MP and try to compile it with our ports/macos, ports/esp32s3 and extmod/tulip and see what breaks. I am certain I've changed something in py but can't find it on a quick diff.

[bwhitman]

I recently upgraded Tulip to latest Micropython. I took notes as i went. If anyone is interested in helping out make us less of a hard fork, here's where to start!

https://github.com/bwhitman/tulipcc/blob/main/docs/tulip_merge.md

[bwhitman]

As of today, see #100 - we are now including Micropython as a submodule (alongside AMY), and esp-idf is installed by the user. On first build (either Desktop or CC), the necessary submodules are loaded.

Big thanks to the MP team for getting MP going on ESP-IDF 5, which opened up a way for us to do this without lots of code changes.

I'm sure there's still some optimization to be done with how we're compiling against MP, but it's working for me on Desktop and CC.

[mattytrentini]

That's a great improvement, nice work! I'll mention this at tonight's Melbourne MicroPython Meetup - there were a few folks interested in your (very cool!) project.

[andypiper]

+1 to this, I'm now running it on the T-Deck (mostly adding here for @mattytrentini info) and interested in looking at other options now! Thanks @bwhitman for the nice integration here.