Building a GUI in Rust that has a python interface/console for scripting

[phlpphns]

Hey there,

Could you suggest a way how to integrate a python console into my Rust app (as part of a gui would be top)? I would like to distribute a set of python interfaced Rust libraries bundled with a gui (and python?). I am thinking about doing it with wasm (has some advantages).

The goal would be to give a working flow and structuring for users by the gui, the python interpreter should enable data processing, preparation, population with data objects and calculating quantities from the values in the data objects and add flexibility. How could one bind things together?

I posted two separate questions in the Rust language forum concerning the issue:

https://users.rust-lang.org/t/discussion-about-code-design-connecting-gluing-rust-libraries-by-python-and-minimizing-costs-for-type-conversion/75943

https://users.rust-lang.org/t/building-a-gui-in-rust-classical-vs-wasm-having-an-interface-console-for-scripting-to-e-g-python/75999

One suggestion concerning wasm was to (since it's html) pipe text both ways and drop it in a terminal library, e.g., https://www.npmjs.com/package/@piopli/terminal-ui

I am really unsure if this is the way to go for integrating a python interpreter into the program. - I think that an overall design would be a "list" of "Rust data objects" that provide and take the input and output for/of various functions. The list links the gui elements and is accessible from python and Rust (gui). The gui and python would have acces to the objects in the list (creating, deleting, extracting, plotting, saving to disk... objects and all kinds of stored data). Python should be able to load all libraries. I think once I have some minimal example I would be able to arrive at more and contribute to the ecosystem.

One idea that comes into my mind would be to use something like eval, run... as found in the documentation, but they are working internally only:

https://pyo3.rs/v0.9.2/python_from_rust.html
https://pyo3.rs/v0.9.2/get_started.html?highlight=interpreter#using-python-from-rust
https://pyo3.rs/master/python_from_rust.html

In my research I found some realizations, so the idea should be working but some don't even compile or cannot load modules, and I cannot figure out how to do it with pyo3 (or at all).. Others are not available in Rust or very slow.
I do not say that the gui must be written in Rust (would be nice though) or that it must be in wasm necessarily (a gui like egui would be acceptable too; all comments and hints would be very welcome!)

https://www.itp.uni-hannover.de/en/groups/weimer/teaching/ideal-gas-simulator/rapid-python-gui-development-with-html5-and-pyodide/

https://testdriven.io/blog/python-webassembly/

https://github.com/amirtds/python_editor_wasm.git

https://wapm.io/_/python

https://rustpython.github.io/demo/

https://github.com/RustPython/RustPython

thank you,
Phil

[davidhewitt]

Hi @phlpphns, thanks for the question, sorry for the delayed response. This sounds like a complicated project, and tbh I'm only just learning about wasm too (#2412), so it might take us a bit of iteration to find a solution for you.

To start, can I ask a bit more about how you want to distribute and run this program? You wrote:

I would like to distribute a set of python interfaced Rust libraries bundled with a gui (and python?).

Does this mean that you'll compile everything to a set of wasm files and then launch it with node? Or in a browser? Will the GUI be an executable that loads the wasm files, maybe embedding something like wasmer?

[phlpphns]

Thank you very much for your reply. It's ok, I see that you are very busy working. I was absent for some time.

That are good questions. In principle I would like to have a set of libraries that are similar to micro services but that they communicate via python. This would make it is easy for users to influence the processes. (I have not yet tested the cost and how to minimize type conversions).

GUI. I want to avoid being stuck at some point because something is stopped being developed. My main interest is how to have a command line (native speed) in the GUI that let's me change objects, plot, visualize, etc to the GUI. - I thought providing it in a browser (then I could host the backend on a server) would be good. If a standalone is possible, it would be also interesting to do that.
I thought about webassembly because many mature ways to build graphical things appear to exist. Initially I thought it would be attractive to have it all done in one language (RUST, memory safety if at one point a good python runtime written in RUST would appear; but I think I'm thinking too far for the moment).
I think the GUi would need to start everything (or maybe a process before?). I think the GUI needs to be the orchestrator and probably everything is interwoven by Python ("communication system"). Does this boil down to the GUI running some predefined python commands and the desired interpreter giving the flexibility of defining new commands? If I'm unclear please tell me.

[phlpphns]

Based on your questions, I did further research and thinking. I present my thought and possibly point (b) below could be a way.

I think that a browser based GUI might be most suitable for shipping and design.
Now the question about wasm remains. Is it the best choice? A probably non-exhaustive list of ideas:

Concerning webassembly, something that has a python interpreter exists: pyiodide and pyscript.

https://github.com/pyodide/pyodide/discussions
https://www.anaconda.com/blog/pyscript-python-in-the-browser

They appear to support one python version only though (pyodide/pyodide#2353) and they are not fully functional (e.g. multiprocessing apparently cannot be invoked due to limits with the wasm) and also do I doubt that new modules can be loaded.

I want to be able to load arbitrary modules on runtime. I want to be able to run code on runtime. I think defining the location of the python runtime by e.g., a configfile to be able to chose a python version and location and to install new modules might be beneficial. One could then decide if the codes that do the main work should be client or server sided, if it's not called from localhost (or so...). As far as I see it, pyO3 is "stuck" with the python version, the binary is created at.

What to do?
a) I could design a standalone python only solution. It should be possible. (I have not yet looked what PyOxidizer can do for us.)

Some routes could exist:

https://docs.python.org/3/library/code.html
https://pypi.org/project/pyqtconsole/
https://www.youtube.com/watch?v=LHX-09SBBtg
https://gist.github.com/daegontaven/a986a2241e15e95be7489f443e79fb7f

But I would not get a wasm solution from a python program because of difficulties owing to dynamic typing in python and wasm being statically typed.

b1) I could try to build a webapp completely in python and see if I could integrate a REPL.
b2) I could try to design some "conventional webpage" OR
b3) a wasm solution
https://stackoverflow.com/questions/11264918/how-to-embed-a-python-interpreter-on-a-website

Assuming we chose (b2) or (b3).
The challenge to solve is how to make communication between the elements happen:
If we say that the GUI manages everything, we would need to pipe text from the GUI to python and the results back. Maybe "sending around" text is enough.
In pyO3, we have PyModule::from_code: https://pyo3.rs/v0.16.4/python_from_rust.html
What do you think about a hardcoded set of standard python commands that are linked to certain buttons in the GUI? Via the console, one could process more advanced commands on the objects. I could predefine a protected list that holds objects that contain data? Functions would operate on the data. That means the GUI, if it starts from a RUST executable, would need to keep one python interpreter, at least the main list with the objects alive and invoke the commands as needed.

I don't know yet if something like a REPL with autocomplete was already realized for a webfrontend. At least something like a text editor with a history should be realistic.
I still need to solve if the functions could accept both pure python and interfaced rust types and if I should worry about type conversions if I had many loops with function calls. I cannot see if it is obvious (Maybe a seperate issue.)

[davidhewitt]

If you want to support multiple Python versions then the only way that I'm aware you can go is to compile a Python extension module using the abi3 features to create a package which can be imported by multiple different Python versions.

Using Pyodide will not prevent you from importing arbitrary packages; they are working hard on adding lots of packages using a tool called micropip.

If you went for (b2) I would suggest writing the GUI in Typescript and using a websocket to communicate with your Python server process. You could also look at just using something like jupyter, perhaps?

I would suggest not thinking about Python and Rust types as being different. One of the main points of PyO3 is that you can write commands from Python without any awareness that the implementation is in Rust.

[phlpphns]

Thanks for your answer. Sorry for my delayed response. I immersed myself in research about the frameworks.

You gave me a lot of good tips. And guided me toward using a vocabulary more appropriate to do the research. I will investigate what can be done by using pyodide/pyscript and probably ask them some technical questions. I will do my best to find a well working solution and provide you with it.