PATCh future development options

Nobody has claimed this yet.

Here are some thoughts on what can be done to improve patch down the line and the relevant implications of each possibility.

We currently render a web app by pointing the original stlite platform (https://share.stlite.net/) to one python file alongside with the requirements, something like this:

https://share.stlite.net/#url=<script_url>?req=<package_1>&req=<package_2>

That makes it impossible to split a big app into multiple files or to import functions from other files. There are many ways we can allow for such a thing, and I’m going to list some of the possibilities that I thought off here, in order of "how much work/time it might take". All of this implementations will require an adapation of the vscode extension as well.

1 – Mount the apps directly in our repo - not very time consuming.

He can render the apps directly in our frontend and point to multiple files. For that, we would need to add some javascript to our current setup and modify the apps.yml file structure a little bit. We would dynamically generate something like this:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8" />
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta
      name="viewport"
      content="width=device-width, initial-scale=1, shrink-to-fit=no"
    />
    <title>stlite app</title>
    <link
      rel="stylesheet"
      href="https://cdn.jsdelivr.net/npm/@stlite/mountable@0.32.0/build/stlite.css"
    />
  </head>
  <body>
    <div id="root"></div>
    <script src="https://cdn.jsdelivr.net/npm/@stlite/mountable@0.32.0/build/stlite.js"></script>
    <script>
      stlite.mount(
        {
          entrypoint: "streamlit_app.py",
          files: {
            "streamlit_app.py": {
              url: "https://raw.githubusercontent.com/data-to-insight/patch/main/apps/000_intro.py",
            },
            "util.py": {
              url: "https://raw.githubusercontent.com/data-to-insight/patch/main/util.py",
            },
          },
        },
        document.getElementById("root")
      );
    </script>
  </body>
</html>

2 - hash the code directly into the url - some time required.

The original stlite sharing platform also accepts an hashed version of the entire code in the url. This makes it possible to render whatever files we want and also to share an app directly with that url. The problem is that we end up with a very long url for each app - which can be too long to share among some platforms. It would also require us to add the functionality to transform the entire apps code into the hash - which might be time consuming.

3 – Have our own version of stlite running - large amount of time required.

We are using a package maintained by mainly one person (stlite). We are uncertain on how it will progress in the future. It might be a good idea to have an independent version of stilte adapted to our needs. That would also bring flexibility on making the proper adjustments to our requirements.

Start by reading the current frontend setup, docs/_data/apps.yml, and the VS Code extension integration. Compare the three proposed approaches, including their implications for multi-file apps, URL sharing, and future maintenance of stlite. Done means selecting and documenting an implementation direction with an agreed scope.

Written by the indexing model from the issue text.

Description

1 – Mount the apps directly in our repo - not very time consuming.

2 - hash the code directly into the url - some time required.

3 – Have our own version of stlite running - large amount of time required.

Contributor guide

First steps

Research direction

Assessment

PATCh future development options

Description

1 – Mount the apps directly in our repo - not very time consuming.

2 - hash the code directly into the url - some time required.

3 – Have our own version of stlite running - large amount of time required.

Contributor guide

First steps

Research direction

Assessment

Get new issues in your inbox