jupyterlite / repo2jupyterlite

Build jupyterlite apps out of repositories

JupyterLite

JupyterLite is a JupyterLab distribution that runs entirely in the browser built from the ground-up using JupyterLab components and extensions.

⚡ Status ⚡

Although JupyterLite is currently being developed by core Jupyter developers, the project is still unofficial.

Not all the usual features available in JupyterLab and the Classic Notebook will work with JupyterLite, but many already do!

Don't hesitate to check out the documentation for more information and project updates.

✨ Try it in your browser ✨

JupyterLite works with both JupyterLab and Jupyter Notebook.

Try it with JupyterLab!	Try it with Jupyter Notebook!

🏗️ Build your own JupyterLite 🏗️

You can build your own JupyterLite website in a couple of minutes, with custom extensions and packages.

See the documentation for more details.

Browser-based Interactive Computing

JupyterLite is all about accessible browser-based interactive computing:

• Python kernel backed by Pyodide running in a Web Worker
  • Initial support for interactive visualization libraries such as altair, bqplot, ipywidgets, matplotlib, and plotly
• JavaScript kernel running in a Web Worker
• View hosted example Notebooks and other files, then edit, save, and download from the browser's IndexDB (or localStorage)
• Support for saving settings for JupyterLab/Lite core and federated extensions
• Basic session and kernel management to have multiple kernels running at the same time
• Support for Code Consoles

Ease of Deployment

• Served via well-cacheable, static HTTP(S), locally or on most static web hosts
• Embeddable within larger applications
• Requires no dedicated application server much less a container orchestrator
• Fine-grained configurability of page settings, including reuse of federated extensions

Showcase

Jupyter Interactive Widgets

JupyterLab Mimerender Extensions

Matplotlib Figures

Altair

Plotly

Development install

See the contributing guide for a development installation.

Related

JupyterLite is a reboot of several attempts at making a full static Jupyter distribution that runs in the browser, without having to start the Python Jupyter Server on the host machine.

The goal is to provide a lightweight computing environment accessible in a matter of seconds with a single click, in a web browser and without having to install anything.

This project is a collection of packages that can be remixed together in variety of ways to create new applications and distributions. Most of the packages in this repo focus on providing server-like components that run in the browser (to manage kernels, files and settings), so existing JupyterLab extensions and plugins can be reused out of the box.

See also:

• p5-notebook: A minimal Jupyter Notebook UI for p5.js kernels running in the browser
• jyve: Jupyter Kernels, right inside JupyterLab
• Starboard Notebook: In-browser literal notebooks
• Basthon: A Jupyter notebook implementation using Pyodide

👥 Contributors

Join our community and become a contributor today! 🚀

repo2jupyterlite's Issues

URL Design plan

Braindump + plan from the plane!

1. Users should be able to copy paste the URL they are in and share it
   with someone else. This should "just work" - unlike how things now go with
   mybinder.org.
2. No state must be maintained anywhere.
3. Is perfectly ok to have some build redirects in there to show people proper
   UI when we need to do a build. We aren't trying to trigger rebuilds for
   requests to JS, for example.

State required for building is:

1. repo provider
2. repo slug
3. ref slug

so a URL structure could be like:

/v1/<repo-provider>/<repo-slug>/<optional-ref>/

So if we get a request for

/v1/gh/yuvipanda/environment.yml/rel/index.html

we parse this out first into:

repo_provider = gh
repo = yuvipanda/environment.yml
ref = rel
file_path = index.html

And we check if the repoprovider, repo, ref exists. If it does, we then
_manually proxy (not redirect) to the source file. This adds additional
complexity - we act as a somewhat inefficient proxy. However, that is the
only way to give the user the experience of being able to copy paste what
they see in their URL bar and 'just' have it work. That is a very important
UX affordance we must offer to people.

1. request comes in
2. We parse the parts out
3. Check if it has been built
4. If it has been built, we proxy out the appropriate files.
5. If it has not been built, we redirect to a build UI.

So simple staticfiles won't be enough.

Add a parameter to allow using Voici!

Problem

It would be great to have an option to use the Voici jupyterlite addon https://github.com/voila-dashboards/voici so that people could generate dashboards easily!

Conflict when trying to clone directory on Mac

repo2jupyterlite https://github.com/boyuai/ipyturtle2 tftest
/Users/tonyhirst/opt/miniconda3/lib/python3.9/site-packages/requests/__init__.py:102: RequestsDependencyWarning: urllib3 (1.26.8) or chardet (5.0.0)/charset_normalizer (2.0.4) doesn't match a supported version!
  warnings.warn("urllib3 ({}) or chardet ({})/charset_normalizer ({}) doesn't match a supported "
2022-11-07 14:25:29,816 Picked Git content provider.

2022-11-07 14:25:29,825 fatal: destination path '/var/folders/l8/qg6m44156_l6bzv_cbkk7bf00000gn/T' already exists and is not an empty directory.

Traceback (most recent call last):
  File "/Users/tonyhirst/opt/miniconda3/lib/python3.9/site-packages/repo2docker/contentproviders/git.py", line 32, in fetch
    for line in execute_cmd(cmd, capture=yield_output):
  File "/Users/tonyhirst/opt/miniconda3/lib/python3.9/site-packages/repo2docker/utils.py", line 74, in execute_cmd
    raise subprocess.CalledProcessError(ret, cmd)
subprocess.CalledProcessError: Command '['git', 'clone', '--depth', '1', 'https://github.com/boyuai/ipyturtle2', '/var/folders/l8/qg6m44156_l6bzv_cbkk7bf00000gn/T']' returned non-zero exit status 128.

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/Users/tonyhirst/opt/miniconda3/bin/repo2jupyterlite", line 8, in <module>
    sys.exit(main())
  File "/Users/tonyhirst/opt/miniconda3/lib/python3.9/site-packages/repo2jupyterlite/app.py", line 105, in main
    fetch(args.url, args.ref, checkout_dir)
  File "/Users/tonyhirst/opt/miniconda3/lib/python3.9/site-packages/repo2jupyterlite/app.py", line 55, in fetch
    for log_line in picked_content_provider.fetch(
  File "/Users/tonyhirst/opt/miniconda3/lib/python3.9/site-packages/repo2docker/contentproviders/git.py", line 40, in fetch
    raise ContentProviderException(msg) from e
repo2docker.contentproviders.base.ContentProviderException: Failed to clone repository from https://github.com/boyuai/ipyturtle2.

Building in a clean environment

When building a jupyterlite environment, does it need to be in a clean environment, free of other jupyter extension packages etc?

If you are running in a new server environment, eg via a GitHub action, then you can probably assume no "contamination". But in the general case, do we need to install and run repo2jupyterlite in a clean Python environment, with any additional repo2jupyterlite dependencies installed? (Isnl'tthat the sort of thing hatch is good at?)

Bring up a `binderlite` test/beta service

As discussed at JupyterCon (@yuvipanda, @jtpio) and especially after seeing @yuvipanda's lighting talk -- a good next step would be to get a test service setup, publicise this and then go from there based on feedback.

Curvenote has some space that is can make available to host this and @yuvipanda I sent you some details out of band - did you get those ok?

Happy to iterate on that to make sure perms etc are set up ok (I have a terraform repo I could share and iterate on for those). Do we need to get anything else in place for this?

Update to `jupyterlite-xeus`

Currently repo2jupyterlite depends on jupyterlite-xeus-python:

repo2jupyterlite/setup.py

Line 17 in 5c848e5

"jupyterlite-xeus-python",

However there has been some refactoring lately to make it easier to load xeus kernels more easily in JupyterLite, with the creation of a new loader package: https://github.com/jupyterlite/xeus

Updating to this new package should hopefully be straightforward. For reference there is a migration guide: https://xeus-python-kernel.readthedocs.io/en/latest/migration.html

build failure in beta service

Description

attempting to launch from the repo https://github.com/stevejpurves/seg_tutorial results in a failure message:

{
"detail": "jupyter lite build failed"
}

Reproduce

see 👆🏻

Launching from https://binderlite-prototype-yuvi.mybinder.org/?

Expected a jupyterlite site to launch, this repo does launch on mybinder.org

Context

• JupyterLite version: https://binderlite-prototype-yuvi.mybinder.org/?
• Operating System and version: MacOS
• Browser and version: Chrome 114.0.5735.90

Browser Output

ParsedRepoURL
index.html:1     Failed to load resource: the server responded with a status of 500 ()
Navigated to https://binderlite-prototype-yuvi.mybinder.org/v1/gh/stevejpurves/seg_tutorial/345defa4edd7186358ff1aee6216d85702b30000/lab/index.html

BinderLite & repo2jupyterlite

Hey @yuvipanda!

This repo is looking really promising. I also just learned about this one as well by @manics: https://github.com/manics/binderlite-builder

With some more context in https://discourse.jupyter.org/t/idea-binder-jupyterlite-binderlite/14449/7

I was wondering if you two had some ideas on how to proceed with the next steps before being able to ship this to end users?

Anyway happy to help with this initiative and fix upstream issues if any, thanks!