whitphx / stlite Goto Github PK

Low priority because;

• Mapping demo does not work due to lack of PyDeck
• Animation demo uses a loop which does not work well

Like

• JS Fiddle
• Shinylive

Great work! I have tried using my code and noticed that st.line_chart doesnt work.

• Universal: PWA (already)
• Desktop: Electron/Tauri
  • This may contribute to streamlit/streamlit#1370
  • Electron looks better
    • It has Web Workers support
    • It has browser and NodeJS runtime
    • Tauri seems to be a "web-based UI framework on Rust" on which the web technology is for UI and Rust for the main process.
      • It seems that Tauri does not have a runtime where Pyodide runs.
  • Package name: @stlite/desktop
• Mobile: Capacitor

It would be nice to just give the url to an existing streamlit app (python code) hosted on github, as we normally do with Streamlit Cloud.

Great work!

During development with yarn start in packages/playground, when new changes are saved and the page is hot-reloaded, stlite-kernel is reloaded but Streamlit frontend stays disconnected.
It should reconnect when the kernel restarts.

It was working fine yesterday but when I tried today I got a page not found message. Here is a link to my screenshot.

Apart the WebSocket communication, Streamlit also uses many HTTP endpoints for various purposes including serving media files and custom component resources.
To make use of these existing HTTP endpoints and the corresponding client implementations with a minimum amount of changes, it looks like ServiceWorker is a good way, compared to re-implementing these communications on top of WebWorker messaging.

Considerations

• ServiceWorker works in a "progressive" manner, so its full functionality may not be available at the initial time before downloading completes.
• ServiceWorker may fail to be installed if the script origin is different from the page origin: w3c/ServiceWorker#940

Does st.download works with stlite? I added a download button to my streamlit app using st.lite but it doesn't work.

Run stlite on Cloudflare workers some PaaS where NodeJS can run such as fly.io or adaptable as a server-side process and serve the page like normal Streamlit.
It may be kind of simpler than stlite on browsers as the necessary part may be patching Tornado to run and handle HTTP req/res on the workers and the upstream Streamlit may run on it without modifications.

UPDATE: Cloudflare Workers are not for such usage as its worker function is expected to run in a short time like 10ms, and even on a paid plan, 30mins.
UPDATE2: Cloudflare Workers doesn't limit the duration: https://developers.cloudflare.com/workers/platform/limits/#duration

We can use https://github.com/pyodide/pytest-pyodide

The upstream Streamlit removed tornado.gen: streamlit/streamlit#4895

https://blog.jupyter.org/jupyter-everywhere-f8151c2cc6e8

Support inputting multiple Python files that are imported from the main script file.

The mountable API would be like this?
This is more general design that covers not only Python scripts but also other types of files.

stlite.mount({
  entrypoint: "streamlit_app.py",
  files: {
    // Python files
    "streamlit_app.py": `
import streamlit as st
...
    `,
    "pages/page1.py": `
# This is the first page.
    `,
    "pages/page2.py": `
# This is the second pae.
    `,
    // Other files, e.g. data files
    "data/foo.csv":  // Text file
`id,name
1,Bob
2,Alice
`,
    "data/secret.dat": new ArrayBuffer(/* Some data */), // Binary file
    "models/foo.h5": fetch("...")  // Support async API?
    "models/compressed.h5": {
      url: "....zip",
      unpack: true. // Unpack the archive: https://pyodide.org/en/stable/usage/faq.html#how-can-i-load-external-files-in-pyodide
    }
  }
})

Reported at https://discuss.streamlit.io/t/new-library-stlite-a-port-of-streamlit-to-wasm-powered-by-pyodide/25556/3

The source code copied:

import streamlit as st
import time

st.set_page_config(
    page_title='Pomodoro',
    layout='centered',
    page_icon='🍅'
)

def count_down(ts):
    with st.empty():
        while True:
            mins, secs = divmod(ts, 60)
            time_now = '{:02d}:{:02d}'.format(mins, secs)
            st.header(f"{time_now}")
            time.sleep(1)
            ts -= 1
            if ts < 0:
                break
    st.write("Time Up!")
    st.balloons()

def main():
    st.title("Pomodoro")
    time_minutes = st.number_input('Enter the time in minutes ', min_value=0.1, value=25.0)
    time_in_seconds = time_minutes * 60
    if st.button("START"):
            count_down(int(time_in_seconds))

if __name__ == '__main__':
    main()

It may hit performance? First, measure it!

It looks like just to set some value to the server.fileWatcherType config:

https://github.com/streamlit/streamlit/blob/1.13.0/lib/streamlit/config.py#L505

https://github.com/streamlit/streamlit/blob/9c2020f28b021a4ae446dccd3de83791b59df759/lib/streamlit/watcher/path_watcher.py#L123

It raises an error such as

6.8fc22a8b.chunk.js:1 TypeError: Cannot read properties of undefined (reading 'embed')
    at BokehChart.tsx:109:13
    at BokehChart.tsx:123:5
    at Ls (6.8fc22a8b.chunk.js:1:1608317)
    at t.unstable_runWithPriority (6.8fc22a8b.chunk.js:1:1626130)
    at qi (6.8fc22a8b.chunk.js:1:1548488)
    at Ns (6.8fc22a8b.chunk.js:1:1607778)
    at 6.8fc22a8b.chunk.js:1:1607689
    at B (6.8fc22a8b.chunk.js:1:1625189)
    at E.port1.onmessage (6.8fc22a8b.chunk.js:1:1623911)

Multi-line log messages emitted from Python runtime are split into single lines and displayed with different console.log() calls.
Multiple lines from a single log source should be aggregated and displayed with a single console.log().

• Developers can use stlite as a NPM package
• Script tag-based import can be used from CDN source from NPM

It uses threading that is not supported in the Pyodide environment and raises an exception, RuntimeError: can't start new thread.

RuntimeError: can't start new thread
Traceback:
File "/lib/python3.10/site-packages/streamlit/runtime/scriptrunner/script_runner.py", line 555, in _run_script
    exec(code, module.__dict__)
File "/home/pyodide/streamlit_app.py", line 10, in <module>
    with st.spinner():
File "/lib/python3.10/contextlib.py", line 135, in __enter__
    return next(self.gen)
File "/lib/python3.10/site-packages/streamlit/__init__.py", line 441, in spinner
    _add_script_run_ctx(_threading.Timer(DELAY_SECS, set_message)).start()
File "/lib/python3.10/threading.py", line 928, in start
    _start_new_thread(self._bootstrap, ())

Note: time.sleep() is no-op on Pyodide, so awaiting would be a bit tricky.

Currently, if some error occurs before the Streamlit server launch, the screen stays "Loading...".
It should indicate the error.

Inject https://github.com/streamlit/streamlit/blob/1.10.0/frontend/src/lib/FileUploadClient.ts

The copy-and-pasted code in stlite-tornado is growing, so it should be replaced with the upstream Git repository and some patches on it.

• Consider to use turbopack or esbuild instead of Webpack, or esbuild-loader with Webpack
• Refer to https://github.com/streamlit/streamlit/blob/1.13.0/frontend/craco.config.js#L66-L93

To use at

• README
• Twitter
• Website

• Preview in WebView
• Auto-reload

By making it as a web-compatible extension, we will be able to use it on GitHub Codespaces which realizes the true in-browser development experience.

PyZQM includes C-extension files that we need to build specifically for Pyodide.

blinker 1.5 now has a pure Python package (*py3-none-any.whl).
https://pypi.org/project/blinker/1.5/#files

Pandas-related components such as st.table or st.line_chart are using PyArrow to pass the data from the server to the frontend, but PyArrow is not working.
PyArrow includes C-extension that we need to build specifically for Pyodide.

• 1. Build PyArrow for Pyodide
  • I tried this but it was not successful, at least in my env; M1 mac + Docker + Pyodide official docker image -> Try it on Linux?
  • Pros
    • Streamlit has already had code using PyArrow, and we do not need to rewrite it.
• 2. Find a way not to use PyArrow
  • Pros
    • Maybe easier to implement
    • Arrow binary is not needed to load, which means the runtime size can be smaller.
  • Cons
    • We need to re-implement the data transport layer and it may leads to difficulty of merging the upstream.
    • [important] Custom-components that handle data-frame-like objects may not work with this because the component library uses PyArrow in its marshaller: https://github.com/streamlit/streamlit/blob/develop/lib/streamlit/components/v1/component_arrow.py#L25
      • They can work if the dependent component-lib can be replaced with our original one.
  • Strategies:
    • a) Using the JS version of Arrow and porting it from JS to Python
      • Pros
        • We can use the existing proto
      • Cons
        • Inefficient: We have to transport the data twice: the first is through Pyodide's proxy to use JS arrow, and the second is through the proto
    • b) Create an alternative data transport layer instead of PyArrow
      • For example, pyodide/pyodide#1168 has been solved by using Pyodide's getBuffer for the needs of ndarray.
      • Pros
        • Efficient: We can transport the data from Python to JS through Pyodide's proxy objects.

Provide a single (or maybe multi) JS file that developers can embed with script tag and just works.

• Access to https://whitphx.github.io/stlite/ (the playground app)
• Wait for the Streamlit app to be loaded
• The browser URL history is pushed to https://whitphx.github.io/
  • This is not HTTP redirect. It looks like history API manipulation
• At the same time, the following error dialog appears
  

  Page not found
  You have requested page /stlite, but no corresponding file was found in the app's pages/ directory. Running the app's main page.
  

This seems to be derived from upgrading Streamlit to 1.10.0: #40 and its multipage app functionality.

A common use case would be installing packages with micropip

https://github.com/whitphx/stlite/pull/83/files#diff-4c5eecd52e82d618b38158b716aa037b0d15179e3bfd4d9d726e33aae4b110ceR157
but, XSRF seems not necessary for stlite?