JetBrains
Support for unix porting of MicroPython
I am using MicroPython not only for embedded devices, but also for writing scripts that have to be super fast, so I wonder if you are planning to support also unix porting. If I am not wrong that would require that the actual micropython interpreter should be available to choose as a project interpreter. Right now it shoots errors if chosen as a project interpreter. If this issue would be accepted as an enhancement I would be happy to help make it work.
@Swington Thanks for your feature request!
There are two options:
- MicroPython for Unix as a new Python interpreter type
In order to be able to add a MicroPython interpreter as a regular Python interpreter, one has to modify the source code of PyCharm itself. From the API perspective it's definitely possible: PyCharm already supports several types of interpreters. But PyCharm requires a Python interpreter to support a number of things:
- Being able to tell the version by running it with a command line option
- Being able to output
sys.pathby runningsyspath.pybundled with PyCharm - (opt) Supporting enough stdlib API to run the pydevd debugger
- Being able to run PyCharm's binary modules introspection tool
generator3.pyto generate Python stubs (or provide a way to turn it off)
- MicroPython for Unix as a new Run Configuration type
It's much easier, since it doesn't affect the rest of PyCharm. But it will require the user to configure two interpreters: the project interpreter (likely CPython) and the interpreter for this type of run configurations.
I'll leave this issue open for a while to collect more votes, opinions, and use cases.
@vlasovskikh Thank you for the problem description!
- MicroPython for Unix as a new Python interpreter type
This solution sounds perfect, but at this moment I don't have the knowledge required to help with some of these issues. I will try to look into those problems.
- MicroPython for Unix as a new Run Configuration type
I think this could be done in the similar manner as the plugin is using now. The Unix version could be selected in the same way as the board type. The problem with this solution, however, could be that the plugin is, at the moment, not really using micropyton interpreter to do any of its operations. It is simply connecting and uploading files to the board. The lib directory is in a way a dummy one used just for typehints. Please, correct me if I'm wrong. This would make Unix porting of MicroPython quite detached from the rest of PyCharm and even a plugin - it would have to use a completely different logic at its core.
@Swington Yes, you're right about (2).
As for (1), one of the key classes in PyCharm is PythonSdkFlavor and its subclasses. But this mechanism is not plugin-ready, all the flavors are explicitly registered at PythonSdkFlavor.getPlatformIndependentFlavors().
@vlasovskikh Are you saying that adding another interpreter type is not something that can be done from the plugin perspective? So this is an issue of supporting MicroPython as an interpreter should be solved in the Pycharm itself?
@Swington (1) is likely to require some changes in the PyCharm Community source code. It's an open question whether it's worth putting all the changes required for supporting MicroPython for Unix to PyCharm Community or it's better just to change it to allow extending interpreter types and implement the rest in the MicroPython plugin.
It looks like I'm not able to set micropython (which is the Unix port, installed on my M1 Mac via homebrew) as a Python interpreter, and the MicroPython plugin can only target a few physical boards (if they are not connected the MicroPython support gets immediately disabled?). Is there a way forward to being able to use the Unix port directly in PyCharm?
