Streamlit: Streamlit in Electron

[DylanModesitt]

Is there a future for electron deployment of streamlit?

---

streamlit electron app.py

I think this has a few key ideas that makes it worth exploring.

1. Streamlit has already changed the game for python application development. IMO, it is the biggest thing in the python web stack since Django. With an electron deployment feature, it could become a big tool for "native" python desktop apps as well.
2. Streamlits target demographic (seemingly the Data Science / ML / AI community) often has apps which consume a lot of resources. RAM for loading data used by the app can be quite a bit- pair this with st.cache and in a few hours/days time your streamlit app needs to be killed / controlled / scaled. That is fine (and good for AWS' profit), but why not be able to "distribute" the app across its users so they can run it on their machine (and use their resources). This is easy enough if your streamlit users are capable of running streamlit run .. in their terminal. However, who are the users of these apps? Oftentimes they will be other engineers / programmers sure - but I think a substantial chunk of the user-base of streamlit apps is a non-technical audience. We send links to streamlit apps to management / non-technical members of the organization constantly I would much rather send them an S3 link to download an electron app and not worry about scaling up the AWS instance(s) hosting it. Sure, they have to have python and some dependencies - but those are relatively easy to control by IT and can often involve little user work. Furthermore, we could maybe have a future where the streamlit build electon command could bundle dependencies? I am not sure - but it seems possible.
3. Streamlit seems well-positioned for this to be possible. It is trivial to "fake it". Just do something like this to get an MVP.

import streamlit as lit  # you guys really dropped the ball on this not being the suggested import
# idk - maybe it is too z00mer.

def main():
    lit.sidebar.title("Electron")
    lit.sidebar.info("The Electron Slide...")
    lit.sidebar.slider('How "nativive"?', 0, 100, 50)
    lit.title("Streamlit in `Electron`")

if __name__ == "__main__":
    main()

Run it,

streamlit run app.py

Take the starter electron app from here. and change literally 1 line (:16)

mainWindow.loadURL('http://localhost:8501/')  // or wherever you served

And...

---

I am just opening this issue to see if you guys (and the community) think this has any legs. I am not sure of the specifics. For example,

streamlit (electron|run_electron) app.py  # for local testing and development
streamlit build -t electron app.py <name>  # for building and bundling dependencies
# to a downloadable launcher? 
...

Could there be electron-specific component implementations (so sidebar could be a native window), or tab support, keyboard shortcuts, etc? Could session state be saved to disk and loaded on app start to preserve state? Or maybe this is all a terrible idea... (also if there is another discussion of this already somewhere else (I couldn't find one) lmk and this can just be closed)

[SimonBiggs]

Hi @DylanModesitt,

I completely agree, this is a wide open field of opportunity. In fact, just a few nights ago I was fiddling with just this. Your post encouraged me to bundle it up into a neat little easy to use prototype.

See https://github.com/pymedphys/pymedphys/tree/master/streamlit-bundle.

Essentially, within a library that I manage I have just added a little command line tool that does some parts of what you describe. Run it within a directory that contains both an app.py and a requirements.txt and it will create for you an installation exe that has an embedded Python installation bundled within it.

You require an installation of yarn, my library tool pymedphys (https://github.com/pymedphys/pymedphys), and if you're building this Windows exe on a Linux machine you'll also need wine installed. See https://github.com/pymedphys/pymedphys/tree/master/streamlit-bundle for more info.

Have this little utility carry with it all the warnings of a rough and ready prototype.

[tconkling]

Hey @DylanModesitt , this is a really cool idea - and thanks @SimonBiggs for running with it!

I'll triage this on our internal feature tracker, and share it with the team!

[psychemedia]

I've also been wondering about bundling freestanding electron apps that carry their own Python distribution with them for running py apps via the electron UI. This is one of the closest recipes I've seen for how to create such a bundle, though I haven't had/made a chance to try it out yet: https://github.com/gollowars/python-electron

[SimonBiggs]

@psychemedia for reference here is the recipe I made to make the CLI pymedphys bundle work:

https://github.com/pymedphys/pymedphys/blob/master/pymedphys/_bundle/__init__.py

[psychemedia]

@SimonBiggs So this is me being slow: does the recipe produce a Windows exe that contains bother the electron app and the complete, standalone py distribution & environment used by the electron app? Does it just build an exe, or does the same workflow work for building executables for other platforms?

What I'm wondering is is how far away this is from something that could be turned into a cookiecutter / template project that would let you select streamlit or jupyter notebook server as the app engine, and bundle the server + notebook + preinstalled requirements into electron apps built for win/mac/linux that run on those platforms without requiring python to be otherwise installed on those platforms. (Further, could a Github Action build these distros just from a Github repo a bit like MyBinder/repo2docker works to build a container from a set of simple text config files).

[SimonBiggs]

Hi @psychemedia it currently builds an electron setup.exe and bundles a Windows 64 bit Python distribution with all the packages declared in requirements.txt pre-installed.

I had previously used a similar recipe for JupyterLab.

This bundles the "Windows Python Embedded" as distributed from the Python.org website. I don't believe they have an "embedded Mac" or "embedded Linux" release. Not that that should be too much a problem.

What is built from the electron side of things, that's just a flag. But there would need to be some OS specific logic.

[SimonBiggs]

As an API, I much prefer a CLI over a cookie cutter template. That way someone can turn it into a cookie cutter, or a GitHub action (or something else) as they please.

I would imagine a config.toml file having items in it such as "JupyterLab" or "Streamlit" as well as "name" "version", "default install path", "os", "icon path" "requirement.txt path" "Streamlit app path" "notebook directory". And then simply running the CLI in a directory with that config file.

[SimonBiggs]

@psychemedia if you install pymedphys version 0.22.* you can see the JupyterLab version of this script. It was removed in version 0.23.0.

See https://github.com/pymedphys/pymedphys/tree/0.22.x/jupyterlab-bundling for JupyterLab instructions. You will need to pin pymedphys to less than 0.23.0 though for it to work.

There was a fatal flaw with that implementation though, see https://github.com/jupyterlab/jupyterlab/issues/7644. I never did investigate further on that one. Streamlit doesn't have that issue though.

Cheers,
Simon

[psychemedia]

@SimonBiggs Thanks for pointers; will try to give it a go... Could be handy as a way of distributing a simple environment to distance ed students, and a bit lighter than a docker container in terms of weight an requirements to install other things (like docker, or fighting with conda etc).

[SimonBiggs]

Could be handy as a way of distributing a simple environment to distance ed students, and a bit lighter than a docker container in terms of weight an requirements to install other things (like docker, or fighting with conda etc).

Certainly. I have learnt that docker is most certainly not the way to go for user friendliness/discoverability. Too much is hidden away from the user. Also, the fact that the visible file system is not the user's file system is an order of magnitude of complexity than what should be there for a new student.

My personal target audience has been other Medical Physicists who are not programmers. I want to be able to distribute the software, while still have the hood slightly open so that those who are curious can take a peak and go down the rabbit hole. I think we likely have quite the overlap in our use cases. Keen for you to ping me on the repo where you are having a play.

Cheers,
Simon

[danlester]

This idea is also something I've been working on - finding a reproducible way to send someone a Streamlit app to run locally on their computer.

I continue to find that (for non-trivial apps) the barrier is always incompatibilities in the Python environment across platforms, or conflicting with existing installed components.

For that reason, my ContainDS Desktop electron app requires Docker (or VirtualBox) to ensure a fully reproducible and compatible experience.

This adds complications, and it would be great if progress can be made for this to work natively instead. However, my process does at least provide a single file that can be shared with others to run on their own computer reliably as described in this article.

(The app launches in the user's own web browser, but as suggested by @DylanModesitt the UI could easily be rejigged to simplify things and embed the Streamlit web page inside the electron UI.)

For non-developers, this works well. As @SimonBiggs says, for half-developers (or students) Docker can confuse their learning, e.g. file system layout is different.

I think it is also worth bearing in mind that Electron installers aren't always straightforward, and each build needs to be signed and (for MacOS) notarised to have any chance of the operating system reacting well to it... and both Windows and Mac seem to be closing up on even allowing the user to choose to bypass these safety checks.

Anyway, based on my experience progress first needs to be made in ensuring reliable portability of the Python environments, interpreters, etc. Adding an Electron front-end should ultimately be possible.

All of this depends on the nature of your app and audience of course. It may remain that different approaches will suit different use cases.

[psychemedia]

@danlester I can't read that article, unfortunately... "To keep reading this story, create a free account."

[danlester]

@danlester I can't read that article, unfortunately... _"To keep reading this story, create a free account."_

I've fixed that now, thanks - made it public. In your case, I think it's functionality you've already tried (exporting as a containds file).

[SimonBiggs]

Anyway, based on my experience progress first needs to be made in ensuring reliable portability of the Python environments, interpreters, etc. Adding an Electron front-end should ultimately be possible.

@danlester what portability issues do you see with the Python environment bundled with the following tool?

https://github.com/pymedphys/pymedphys/tree/master/streamlit-bundle

[danlester]

@SimonBiggs Sorry - I didn't mean to discourage the bundling approach if it works for you and your audience! Pure Python code should work well of course, binary Python packages might need a bit more care, and then I'm thinking that non-Python dependencies such as Tensorflow would be hard work...

I was really talking of generic Streamlit apps which might make use of a broad range of technologies in their models. And I was also considering Mac, Win, and Linux which then increases complexity of code (whether bundling or not) compared to always targeting Linux through Docker.

Of course I realise that for your particular project you know it better than I ever could! I haven't played with the bundling approach for a few years to be honest so I'm happy to hear that things have worked well in your case.

[SimonBiggs]

:) no discouragement felt :). You did answer my question though, main downsides of the approach proposed is primarily the difficulty of maintaining cross platform support. I would argue though that a CI approach that creates a Python bundle for each platform is not too out of reach.