Micropython plugin NOVA

[elmot]

Let's build another UI for the plugin, closer to ideas implemented in Thonny:

• [ ] Migrate from outdated and buggy adafruit-ampy, use direct connection via serial line and websockets instead
  • [ ] Webrepl support (see #42)
  • [x] #302
  • [ ] #307
  • [x] #305
  • [x] #308
  • [x] #304
  • [x] #306
  • [ ] #303
• [ ] File manager (see #239, #178)
  • [ ] #298
  • [x] #299
  • [ ] #301
  • [x] #300
  • [x] #309
  • [ ] Support drag-n-drop files in the file manager(low priority)
• [ ] UI improvements
  • [ ] #310
  • [ ] Instant code fragment execution ( see #182)
  • [ ] Rework settings UI
  • [ ] Drop unnecessary parts of old UI
• Misc tasks
  • [ ] Investigate if we can use linux port for testing
  • [ ] Investigate if we can use qemu port for testing
• [ ] #311
  • [ ] Upload single file
  • [ ] Upload whole project
  • [ ] Activate REPL after upload
  • [ ] Soft reset after upload

[lukaskremla]

Thank you for picking up support of this useful plugin again! The list of upcoming features looks great, I am really looking forward to the update.

Only two things to add, could we also get standalone support for ESP32 devices? They work through ESP8266 but I am not sure if that is the way they are meant to work. And talking about making the plugin more like Thonny, the flashing speed is sometimes quite slow for uploading larger files (websites that have over 1 mb can take a while to upload. Speeding up the flashing would also make working with this plugin more pleasant.

[elmot]

Thanks, that's our plan, but we have a very low manpower now. So any contribution, especially in testing, is more than welcome.

Standalone ESP32

Well, I tried ESP32 as ESP8266, and it more or less works. Actually we hardly can keep up with all the boards and board variants, so I'd prefer make boards support more generic. For best boards support, please push micropython guys to publish better stubs for their libraries.

flashing speed Yeah, that's a problem. I hope that getting rid of adafruit-ampy should help a lot. Out of my experiments, webrepl upload is drastically faster than serial, and I am focusing on that first. Thanks to ESP32 nature, that platform is going to be improved a lot.

[Josverl]

For best boards support, please push micropython guys to publish better stubs for their libraries.

micropython-stubs maintainer here;
@elmot Can you be a little bit more specific on what you need ? As far as I am aware you are currently bundling stubs that are mostly a few years old , while there are much newer versions that already work in PyCharm.

Im sure they are not perfect , but neither are outdated stubs. If I know what you want , then it may be possible to close the gap with , and reduce effort overall.

[elmot]

@Josverl, that's cool to see your encourage. Yeah, now the stubs shipped are quite old, there were no active maintainers for a while.

I'd prefer to download the stubs from somewhere rather than keep ours inside the plugin. But don't see a reliable way to do that.

I think I have seen your repository, and I could not find the algorithm to find the best stub for a particular board. Please help and give me the algorithm I can use.

[Josverl]

Pip is your friend.

The stubs for all released versions are published to PyPI, so if you know the port, and optionally the board, you can use pip to install the stubs into a venv or folder. pip install -U micropython-<port>[-<board>]stubs --no-user --target ./typings

For both boards and ports you need the identical names as used in the micropython repo.

Adding a version or requirements-dev.txt file makes that more repeatable. see

I have rolled-my-own docs for pycharm configuration, But more than happy to add or integrate with this project on specific or alternate instructions.

Update: I have automated the generation of the docpage that lists of all stub packages available on PyPI. https://micropython-stubs.readthedocs.io/en/main/packages.html

[Josverl]

One thing that is good about the manual updates that have been done on the stubs in this repo is that there contributors have taken the effort to improve the paramater and return type annotations beyond what I am able to generate automatically. This was started by Howard Lovatt and continued by others, partly based on the micropython-stubs as is clear in several if not most of the stubs. I do note that corresponding license has not been included, but I assume this has been an unintentional oversight.

I have ben considering to merge these annotations and @overloads (back) into the micropython-stubs. They will need to be verified against drift/differences with the current v1.23.0 ( and -preview) interfaces, either manually or automated. Whether or not I will actually do this will depend on the licensing , as I aim to keep the stubs under MIT license.

The plans in the MicroPython org are to 'adopt' the micropython-stubs and use them as the base for documentation (rather than the reverse) . While the the timelines are not quite clear, the intent is.

In the mean time I keep looking for improvements , this is something that could possibly reduce the effort here, while improving the quality overall.

[elmot]

Thanks, that's goldy. I am afraid this piece of work is a bit out of scope of NOVA, that's next step. I'd now focus on the new UI and the communication level, and then to a new stub approach.

[Josverl]

Makes sense, there are a few other options as well, Tracking progress in the stubs repo : https://github.com/Josverl/micropython-stubs/issues/762