Skip to content

Add trove classifiers for JupyterLite#241

Open
agriyakhetarpal wants to merge 1 commit intopypa:mainfrom
agriyakhetarpal:jupyterlite-classifiers
Open

Add trove classifiers for JupyterLite#241
agriyakhetarpal wants to merge 1 commit intopypa:mainfrom
agriyakhetarpal:jupyterlite-classifiers

Conversation

@agriyakhetarpal
Copy link
Copy Markdown
Member

Request to add a new Trove classifier.

The name of the classifier(s) you would like to add:

  • Framework :: Jupyter :: JupyterLite
  • Framework :: Jupyter :: JupyterLite :: Extensions
  • Framework :: Jupyter :: JupyterLite :: Extensions :: Prebuilt

Why do you want to add this classifier?

JupyterLite (docs, GitHub organisation) is a WebAssembly-powered rendition of JupyterLab that runs entirely in the browser. By eliminating the need for a server-side backend, it allows for instant-access, installation-free interactive computing, with various extensions and kernels available, notably among the Xeus kernel protocol and its various implementations, the Pyodide kernel powered by the Pyodide project, and many more. Some salient points:

  • At the time of writing, a search for the "jupyterlite" keyword on PyPI shows 181 hits: https://pypi.org/search/?q=jupyterlite
  • JupyterLite has gained significant momentum because it solves the "last mile" problem of setting up Python environments. As a result, it is heavily used in education and interactive computing. It has been at the centre of discussion at various Python conferences all around the world, some of which are available through this webpage: https://pyvideo.org/search.html?q=jupyterlite
  • As of February 2026, JupyterLite has officially joined Project Jupyter (blog post). It has powered the "Try Jupyter" button on the Jupyter website even before this change and is increasingly used for interactive, executable documentation in scientific Python projects such as NumPy, SymPy, scikit-learn, and scikit-image.
  • It also finds use for workshops, hackathons, and blogging, as users only need a URL to start coding and set up a Jupyter-like IDE for themselves, and can be hosted on static site hosting providers that are commonplace, such as GitHub/GitLab/Codeberg Pages, Netlify, Vercel, and so on.
  • It is compatible with both the Pyodide distribution (we have a classifier for it via Add Pyodide framework #206 already), which offers a quasi-PyPI ecosystem of WASM wheels, and the emscripten-forge distribution, which is the conda counterpart and offers conda-format packages.
  • It is also the backbone of https://notebook.link, a service launched to run and share notebooks with a single click.

Tagging some core members of the project here for visibility: @jtpio, @IsabelParedes, @martinRenou, @bollwyvl, @ianthomas23. I apologise if I missed someone prolific—I probably did—it is not intentional!

@bollwyvl
Copy link
Copy Markdown
Contributor

It might have been better to work this out upstream, but sure; makes sense at this point. Some thoughts:

Prebuilt is not needed: the alternative (source extensions) are a) deprecated upstream and b) were never supported in JupyterLite. Indeed, at present there is no mechanical difference between "a jupyterlite extension" and "a jupyterlab extension," that would help a user make an informed decision.

There is a whole separate class of things which I don't have a glib term for an author to claim "this python package works in browser-based Python kernels running in JupyterLite," of which we know of jupyterlite-pyodide-kernel, and the not-just-PyPI path to xeus-python running in the browser. While both of those are first-party Jupyter packages, they rely heavily on the whims of many, many upstreams, so it isn't guaranteed that even a given pure python package will work in both, or even between versions of one, as the WebAssembly/Emscripten space continues to shift. So today, perhaps just the "weak" claim of Framework :: Jupyter :: JupyterLite would be sufficient for kernel-compatible libraries, with :: Pyodide and :: Xeus to be addressed on some future PRs with the appropriate contributors.

Some useful distinction for users to discover packages would, however, be along the axis of provided capability. The key ones that come to mind:

  • Framework :: Jupyter :: JupyterLite :: Browser Apps
    • provides a new, separate app (e.g. an index.html)
    • might not work with all other extensions
    • off the top of my head, only voici comes to mind
  • Framework :: Jupyter :: JupyterLite :: Extensions :: Browser Kernels
    • provides the JS assets for a browser-based kernel which should work in any App
    • some examples would include:
      • jupyterlite-pyodide-kernel
      • jupyterlite-javascript-kernel
      • jupyterlite-p5-kernel
  • Framework :: Jupyter :: JupyterLite :: Extensions :: Browser Shims
    • provides some "real server"-like capability not otherwise present in the core package
    • this is kind of a grab bag, but would cover different storage providers, third-party SaaS integrations, etc.
  • Framework :: Jupyter :: JupyterLite :: Embedding
    • provides a way to embed JupyterLite in some other application
    • presently jupyterlite-sphinx comes to mind, but there are a few others out there
  • Framework :: Jupyter :: JupyterLite :: CLI
    • extends the jupyter lite CLI in some way
    • of the above, jupyterlite-pyodide-kernel and voici would also use this one
    • jupyterlite-xeus doesn't directly provide any kernels, but rather wraps a number of other tools to download kernels, so certainly this, but maybe Kernels (and probably won't work directly after a pip install).
    • technically these are Python-level entry points (which would be a whacking good addition to PyPI discovery), and internally referred to as Addons, but neither is going to help someone looking for a package

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants