Disable source maps for the deployment from this repository?

[agriyakhetarpal]

Hi! The JupyterLite deployment from this repository is currently being used by the NumPy live shell on the numpy.org website, and we have recently been expanding shells for more websites for projects as a part of Quansight-Labs/czi-scientific-python-mgmt#134, with potentially the long-term inclusion of a theme-specific attribute for the Scientific Python Hugo Theme as a configuration option to enable a partial for the shell if set, which could make use of this deployment.

I would like to ask if it would be a good idea to disable source maps here? It would significantly reduce the shell's load time as a result of less bandwidth consumption, as the assets' size would come down significantly. This is in line with the results noted for SymPy's live shell recently: sympy/live#24 (comment) via https://bit.ly/sympyjstest.

I have to note that this might not be pleasant for newcomers, as this repository is also meant to serve as an entry point to JupyterLite and is, therefore, built with custom configuration(s) kept to a minimum.

If the answer is negative, no worries and I would completely understand – we could proceed with hosting our own deployment on our side from the https://github.com/numpy/ (or github.com/scientific-python/) organisations.

If yes, I'm happy to open a PR – it's a trivial change to add, of course.

Thank you for your time! :)

---

cc: @rgommers

[jtpio]

Thanks @agriyakhetarpal for the suggestion 👍

Indeed the numpy website currently links to this demo deployment. If I recall correctly this was mostly for convenience. In numpy/numpy.org#557 it was suggested to use a custom deployment, but there were no follow-up discussions on this.

There are indeed pros and cons for keeping the source maps. For example they can be useful to debug issues in custom deployments, directly in the browser.

If we end up making this change in this repo, maybe we then need to have more visible documentation in the README or in the JupyterLite documentation to explain how to enable them back.

[agriyakhetarpal]

Thanks @jtpio! Yes, I would also be on the side of having a custom deployment for NumPy – maybe it makes more sense for everyone to have one rather than having a shared one for all packages under the Scientific Python organisation. It would allow more customisations such as shipping additional Pyodide wheels, or having one's environment.yml if they wish to use Xeus. However, losing out on this convenience and asking projects' maintainers to maintain yet another repository is a no-go, indeed, and this is where—on second thought—having a shared deployment for Scientific Python could make sense.

Another option I've considered is that we can have a copy of this repository built with source maps disabled, as it's not possible to disable source maps at runtime.

Or, is it somehow possible to have two deployments routed from the same GitHub Pages branch? That is, would the act of having two REPLs at https://jupyterlite.github.io/demo/repl/index.html and https://jupyterlite.github.io/demo/prod/repl/index.html with a stub prod/index.html file between them work? Such a way would also help me with sympy/live#28 and make that work significantly more straightforward. That said, I don't wish to put forward more work for you and other JupyterLite maintainers in maintaining this repository, either.

[jtpio]

having a shared deployment for Scientific Python could make sense.

That sounds like a good tradeoff. One of the main drawbacks of depending on https://jupyterlite.github.io/demo for downstream demos is that we regularly update that deployment with newer versions of JupyterLite. And there might in the future be a breaking change or a change in the defaults which would directly affect sites like https://numpy.org.

Also https://github.com/jupyterlite/demo includes a JavaScript kernel by default, which may not be that useful for scientific python. So a custom deployment could decide to include only the relevant kernels and extensions.

somehow possible to have two deployments routed from the same GitHub Pages branch?

While likely possible, there is indeed a risk of adding complexity to this repo, whose initial purpose is to make it as easy as possible for anyone to create their JupyterLite website. The path of a custom (shared) deployment may sounds like a simpler approach in comparison?

[agriyakhetarpal]

That sounds like a good tradeoff. One of the main drawbacks of depending on jupyterlite.github.io/demo for downstream demos is that we regularly update that deployment with newer versions of JupyterLite. And there might in the future be a breaking change or a change in the defaults which would directly affect sites like numpy.org.

I agree, this is another reason as well.

The path of a custom (shared) deployment may sounds like a simpler approach in comparison?

Definitely! And as long as most packages conform to https://scientific-python.org/specs/spec-0000/ and emscripten-forge and Pyodide keep updating them, it would be possible to continually keep them updated in the shell for their interoperability and having an environment that doesn't take ages to solve.

I can, in the meantime, take a deeper look at deploying multiple deployments from a singular GitHub Pages branch, and if I find a non-invasive approach to do that, I can document it under https://jupyterlite.readthedocs.io/en/stable/howto/index.html#deploying (or under the "Advanced" section) – hopefully that will be helpful for users who need such functionality.