REMI: Python REMote Interface Library | Hacker News Reader

REMI: Python REMote Interface Library

github.com

120 pointsamasad47 comments

We (at repl.it) discovered remi when we were looking for a native GUI alternative. Found remi and was able to write a TicTacToe game in 30 minutes, it felt natural and the app is fast enough to not notice it's remote. Take a look (source code there too):

https://repl.it/talk/share/Python-GUI-Tic-Tac-Toe/6145 (might not take the HN load tho)

The reason we started looking into it is that we have a lot of users wanting[1] to write GUI apps and although we support all the major Python web frameworks[2], users, especially novices, still find it easier to write native GUIs. And I can't blame them, after you've learned a bit of Python, learning to write web apps is a whole new ballgame (HTML and CSS are a different style of code altogether that warps people's minds at first).

Here is a basic demo that renders a plot (using matplotlib) if you want to fork and play around with it: https://repl.it/@amasad/remi-repl-demo

[1]: https://repl.it/talk/ask/does-tkinter-work/6685

[2]: https://repl.it/languages/django

Hey -- Just want to give a shout-out and big thanks to the folks at repl.it!!! I love it! I'm teaching college kids who have never written code and repl.it is my platform of choice for quick examples while in the middle of a lecture. At the end, I just save it, and the kids can come revisit the in-class examples whenever they want. It's a great teaching tool! Thanks!!!

yeah, I also love repl.it it's surprisingly easy to use, and really powerful

It contains also a Graphical Editor https://github.com/dddomodossola/remi/tree/master/editor that produces directly python code. no transition metalanguages.

Hello everyone, I'm the creator. I can reply your questions, if you want. last release was this month.

Just wanted to say thanks!

you are welcome :D

How does this compare to Dash by plotly and also Jupyter Dashboards?

At first glance the use cases seem different (applications vs dashboards) but they both provide widgets and GUI elements. Are there things that would be much simpler/quicker in one vs the other?

correct, they seems different but you can achieve "same results" with both. dash is really powerful for look n feel and for plots. but I see it a bit confusional for callbacks and object oriented development. I never used it, so maybe I'm not the right person to ask for a comparison.

Thanks

Hi, is it possible to interact with js libraries? Like leaflet to integrate maps.

yes of course, you can include js libraries in App constructor and execute js by doing app_instance.execute_javascript(jscode)

Seems great! I used https://github.com/miyakogi/wdom a few times but it wasn't satisfying because you have to get your hands dirty with js when you want to customize things (not in js libs but with the widgets).

Sorry if I'm being rude.

How does remi compare to https://github.com/flexxui/flexx?

For example, flexx can translate parts of the app to JS to have a more reactive experience.

good question, comparison beyween projects is a good investigation method. they are really similar projects. flexx has more modularity and depends from powerful libraries like Tornado. Remi has its own webserver and has zero dependencies, not necessarily a good choice but however a notable difference.

I'm not sure if author know about Shiny, it's basically same concept, write html GUI in R, serve with a web server. Shiny is quite mature, and I feel they have some good parts that can be inspring:

It's good to only code GUI in one language, but it's kind of unavoidable that you still need to learn html and css (even javascript) if you want to more control and customization.

- Shiny have some html tag functions to make it really flexible to construct html.

- You can customize css by adding your own.

- Shiny support adminLTE dashboard and bootstrap styles, DataTables js library, interaction with plot and DataTables.

Similar to Shiny is Bokeh for python, which appears to be trying to replicate the Shiny experience. While you can only get so much control without resorting to JS injections, it's pretty good for [select options -> search -> visualize result] type of problems.

Never seen Shiny, I will give it a look. thank you

There's also Dash by plotly

Does it have any protection from malicious js on another site (say a bad ad on a news site) connecting to your application?

I have seen some applications like this, but they fail to check the origin header.

No protection, it have to be intended as a full featured, standalone and remotable gui framework

I don't quite understand your answer. As the readme says: > Remi should be intended as a standard desktop gui framework. The library itself doesn't implement security strategies, and so it is advised to not expose its access to unsafe public networks.

So if listening on localhost to provide a GUI on the users desktop, is it not meant to be protected from attacks from the web?

you are right, it requires further explanation. it is intended to be used on localhost and also on the web, preferably on safe networks like VPN. it implements ssl encription and a basic http authentication. technically it should be safe, the connected client can access only the exposed functions. furthermore each instance exposes methods identified by dynamic object instance id, and unless the developer defines a fixed identifier for a specific method, it should this dynamical definition makes really difficult to programmatically access specific functions. I consider it unsafe because I never spent enough time to test the framework penetration resistance.

That's scary. Listening on localhost or serving a LAN/VPN behind a firewall does not make your web app secure from attackers on the Internet unless you air gapped. HTTP Basic Auth and HTTPS doesn't change that. Please do read up on CSRF.

This has been an issue for decades and just recently been in the news due to massive attacks against home routers (web apps listening on the LAN) and desktop apps (both web apps and web APIs listening on localhost). I get the impression that this has not been considered.

https://en.wikipedia.org/wiki/Cross-site_request_forgery

thank you so much for the advice. however, as previously mentioned: technically it should be safe, the connected client can access only the exposed functions. furthermore each instance exposes methods identified by dynamic object instance id, and unless the developer defines a fixed identifier for a specific method, it should this dynamical definition makes really difficult to programmatically access specific functions. this means that the attacker have to know the ID of an object instance, in the actual running instance to point to a defined function.

however, the safety of an application is up to the developer, that can leave opened also the door of a safe atomic bunker

Am I correct to interpret this as it's up to the app developer not to put any features that do anything of any importance in the web interface, because one should operate under the assumption that it's not only the logged on user in front of the computer (even when address='127.0.0.1') that can press the buttons?

Unless I'm completely misunderstanding I don't agree that is at all comparable with the security model expected of a "standard desktop gui framework" nor safe.

Though indeed if there are large, random and unpredictable IDs required to perform actions it may defeat or make the attack difficult.

you are correct it could be theoretically pressed by someone else, but it should be really difficult because of the unpredictability of IDs. It should be simpler to attack flask or django based webinterfaces. doesn't it?

Unpredictability is an inconvenience. Django and Flask does feature reliable protection.

https://docs.djangoproject.com/en/stable/ref/csrf/

https://flask-wtf.readthedocs.io/en/stable/csrf.html

thank you for the advice. it should be pretty simple to protect an app from that kind of attacks. however this doesn't mean that remi is a safe web framework. personally I feel like @nicolaslem (look at his comment).

nicolaslem recommended hosting behind a reverse proxy. That has nothing to do with the issue.

My recommendation is you read up on the subject and I'll leave it at that. You have been given everything needed to search for more information.

Does this support HTTPS?

I'm building an app using Bottle as the framework and getting HTTPS to work properly (with a proper certificate) has been a nightmare. I think I fixed it after a full day of research and tinkering yesterday.

This app is super small... maybe 5 users simultaneously, so I don't need the overkill of Django or integrating with something on Apache or Nginx.

REMI looks pretty straightforward and lightweight; even without HTTPS it looks useful... I'll give it a whirl and keep it in my bag of tricks!

Yeah. Here is a remi app on https https://tictactoe--amasad.repl.co

yes, https is supported. you have to config 3 parameters in the "start" function call: certfile: ssl certificale filename keyfile: ssl key file ssl_version: authentication version (i.e. ssl.PROTOCOL_TLSv1_2). If None, disables ssl encription

Awesome! That's great news! I may try to rewrite some parts of my app and see if REMI is a good fit.

Bottle is great if you have a simple use case... but getting HTTPS going was horrible. I can't count how many back-end engines I tried (cherrypi, paste, cheroot, gevent, waitress, etc.). Finally got it working on gunicorn.

I'd love to find a framework that abstracts all this away so I don't have to think about it...

I hope you will feel ok with remi. ;-)

Just my two cents, but there are good reasons why Python web frameworks are encouraged to sit behind a reverse proxy:

- Security, most WSGI servers are not designed to handle bad actors like intentionally slow clients. It is usually trivial for a client to DoS your application.

- Separation of concerns, letting your framework focus on its core job rather than pilling features related to crypto and certificate renewal.

The fact that you struggled getting HTTPS to work probably means that you were heading the wrong direction. I suggest to take a look at Caddy[0]. It is a small, handles HTTPS automatically and is super easy to put in front of a Python application.

[0] https://caddyserver.com/docs/proxy

correct, good point of view. thank you for the advice

I have worked with it and it's great. Any thoughts on using an established css framework (i.e. bootstrap)? Because manually sizing all controls for different monitors and complicated layouts are cumbersome.

there are some additional container widgets than in the past that allows auto sizing and positioning. these are VBox HBox (for flex layouting) and GridBox. however someone successfully integrated bootstrap in his application using remi. personally I see it an unuseful complication. thaks to its lightweight infrastructure, a remi page occupy only few kilobytes.

Looks good except that the previous release was made in 2015.7, that's a long long time

That doesn't always mean bad things. Especially for a stable python library. But the JavaScript part could be a bit dusty.

I wish it was easier to find the signal on, "is this project abandonned?" "Does it still work?"

I see new commits tho..

Davide Rosa (author) is so responsive. I'm speculating but I think it was flying under the radar before we found at repl.it.

We see Davide helping people on our forums and fixing bugs as they come.

https://repl.it/talk/ask/Python-GUI/6924

The last release is a few weeks old: https://pypi.org/project/remi/#history

Just because at some point they did GitHub releases doesn't mean they still do, especially when the installation instructions only mention other channels.

v1.2.2 18 days ago

https://github.com/dddomodossola/remi/releases/tag/v1.2.2

Anyone tried to make an apk with Remi via p4a?

I used it directly on Android with termux and qpython, but never packed it into apk.

Reply on news.ycombinator.com