Skip to content
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.

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

Support for unix porting of MicroPython #30

Open
Swington opened this issue Jan 17, 2018 · 5 comments

Comments

@Swington
Copy link

commented Jan 17, 2018

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.

@vlasovskikh

This comment has been minimized.

Copy link
Owner

commented Jan 17, 2018

@Swington Thanks for your feature request!

There are two options:

  1. 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.path by running syspath.py bundled with PyCharm
  • (opt) Supporting enough stdlib API to run the pydevd debugger
  • Being able to run PyCharm's binary modules introspection tool generator3.py to generate Python stubs (or provide a way to turn it off)
  1. 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.

@Swington

This comment has been minimized.

Copy link
Author

commented Jan 17, 2018

@vlasovskikh Thank you for the problem description!

  1. 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.

  1. 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.

@vlasovskikh

This comment has been minimized.

Copy link
Owner

commented Jan 17, 2018

@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().

@Swington

This comment has been minimized.

Copy link
Author

commented Jan 18, 2018

@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?

@vlasovskikh

This comment has been minimized.

Copy link
Owner

commented Jan 18, 2018

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.