I am excited to introduce JupyterLab Marketplace - a community-run catalog of available JupyterLab extensions that surfaces real signals for each extension (PyPI downloads, GitHub stars, last release date).
Try: https://labextensions.dev
Repo: GitHub - orbrx/jupyter-marketplace: JupyterLab Extensions Catalog
Feedback / issues: Sign in to GitHub · GitHub
Why this exists
End users (researchers, data scientists)
- No unified marketplace like VS Code; discovery is scattered across PyPI, repos, and blog posts. (see No marketplace for jupyter extensions? )
- Hard to judge trust quickly (is it active? widely used?).
Extension developers
- Metrics are spread across GitHub and PyPI; hard to see everything in one place.
- Difficult to compare with adjacent tools or show progress to users/stakeholders.
- New authors can’t easily scan what already exists and where gaps are.
Project Jupyter / ecosystem stewards
- Hard to quantify the “liveliness” of the ecosystem and show platform growth to stakeholders/funders.
- A lack of extension catalog makes it difficult to gauge adoption, activity, and areas to invest.
What’s in the beta today
-
Search across name, summary, description, author
-
Sorts: New & Rising, Popular (last 30 d), Most Downloaded, Most Stars, Recently Updated, Name (A–Z)
-
Cards show GitHub stars, 30-day & all-time PyPI downloads, and “Updated X days ago”
-
Install guidance that works in normal and read-only/JupyterHub environments
-
Nightly refresh; public, read-only data view documented on the About page
Note: PyPI “downloads” are download events (a good proxy), not guaranteed installs.
How it works (data pipeline)
-
PyPI BigQuery for metadata + download stats.
-
Filtering out packages that are no longer published on PyPI + a small blocklist of extensions
-
GitHub API for stars/issues/recency
-
Curated into a read-only Supabase view consumed by the Next.js frontend
-
Scheduled daily BigQuery aggregation and GitHub Actions workflow to update Supabase
-
Privacy-respecting: no accounts; preferences live in your browser
Get your extension listed / fixed
If your package uses the Framework :: Jupyter :: JupyterLab :: Extensions classifier on PyPI, it should appear automatically after the next refresh.
Missing or incorrect? Please open a Data correction issue with the PyPI name and the fix. We try not to have ad-hoc fixes, but rather update the data pipeline to deal with the all similar issues at once.
Looking for feedback
- Would a small deep-link hook in the Extension Manager (to pre-focus a package) be acceptable upstream?
- What would be the most useful addition for discovery:
- last supported major version of JupyterLab (i.e.
Framework :: Jupyter :: JupyterLab :: 4)
- extension categories and tags (theme, frontend/backend, AI tools)
- security scans
- Volunteers for curation/testing and org verification are very welcome.
Live demo on the Community Call
I am aiming for a brief demo and Q&A on the Jupyter Community Call at Sep 4, 2025 at 15:00 UTC:
Would love your questions and early feedback there or in the repo.
This is a community project built by Orange Bricks and is not affiliated with Project Jupyter. The Jupyter® trademark is registered with the U.S. Patent & Trademark Office by LF Charities. © 2025
8 Likes
Wow, this is amazing - thank you soo much @ktaletsk! So many interesting extensions get surfaced, much easier to navigate than PyPI.
It would be good to stress that many of the extensions will be compatible with Notebook 7+ but we currently do not have a trove classifier to signify this. Would it be useful to create one?
5 Likes
Quick update on the JupyterLab Marketplace (labextensions.dev) since the original post 
What’s new
- Recording from the Community Call I did a short demo + Q&A on the Sept 4 Jupyter Community Call.
-
JupyterLab version filter The catalog now exposes a “JupyterLab 4” filter, based on Trove classifiers and package metadata. It’s still “best effort” (see lessons learned below), but already useful if you’re trying to find Lab 4-compatible extensions quickly.
-
Launch in Binder & GitHub Codespaces From any extension page you can now jump straight into a cloud environment with that extension enabled.
-
Create Badges You can now generate badges showing the number of downloads over speicifed period of time
Markdown template:
[](https://labextensions.dev/extensions/<extension name>)
-
Upcoming talk at PyData Boston The marketplace and ecosystem data will be part of my talk at PyData Boston 2025 (Dec 10, 4:15 PM).
Abstract
The JupyterLab Extension Ecosystem: Trends & Signals from PyPI and GitHub
What does the JupyterLab extension ecosystem actually look like in 2025? While extensions drive much of JupyterLab’s practical value, their overall landscape remains largely unexplored. This talk analyzes public PyPI (via BigQuery) and GitHub data to quantify growth, momentum, and health: monthly downloads by category, release recency, star-download relationships, and the rise of AI-focused extensions. I will present my approach for building this analysis pipeline and offer lessons learned. Finally, I will demonstrate of an open, read-only web catalog built on this data set.
What & why
JupyterLab extensions drive much of the practical value for data teams, but discovery and evaluation are noisy. This talk uses public data (PyPI/BigQuery + GitHub) to measure the ecosystem with transparent signals, not black boxes.
Scope.
We quantify growth over time, category composition, release cadence, and popularity patterns. We examine where simple signals (30-day vs. all-time downloads, stars/issues, “updated X days ago”) correlate—and where they don’t—then zoom in on the AI segment to separate durable adoption from hype.
Methods
- Data: PyPI download events (BigQuery public dataset), project metadata, and GitHub repository stats.
- Processing: Daily summaries to control cost; package↔repo mapping; cautious enrichment under rate limits.
- Caveats: Downloads ≠ installs; stars ≠ quality. We treat them as proxies and show their limits.
- Reproducibility: A read-only aggregate snapshot and the core queries will be shared so attendees can reproduce/extend the analysis.
Companion catalog (brief demo)
We’ll spend a few minutes in a companion, open web catalog (open-source client; public read-only API) to show how practitioners can search by category, slice by recency/downloads/stars, and copy install commands—using the same dataset.
Takeaway
- How the ecosystem is growing and which categories lead.
- What “healthy” looks like (recency, contributor activity).
- Evidence on AI-extension adoption vs. attention.
- A lightweight recipe to measure other plugin ecosystems.
Outline with time breakdown (40 min incl. Q&A)
- 0–5: Why measure extensions? Signals vs. noise; data sources; caveats
- 5-15: Trends in the data (growth & composition, momentum/health, growth of AI)
- 15-20 Companion catalog live demo (search/sort; copy install; how signals map)
- 20–30: Methods & reproducibility (pipeline thumbnail, queries, snapshot/API, limits)
- 30–40: Q&A
Audience & prerequisites.
Data scientists/engineers, OSS maintainers, and tool builders. Comfortable with Python/SQL basics; no Jupyter internals required.
I’d love feedback on:
- What ecosystem questions you’d like answered (health, adoption, categories, etc.)
- What signals would be most useful to highlight for users/developers/maintainers
Lessons learned so far
- Self-reported metadata is fragile (but fixable) A lot still depends on how extensions declare themselves on PyPI:
- Some packages didn’t update their Trove classifiers when they added JupyterLab 4 support. A concrete example (spotted by @jasongrout):
jupyterlab-widgets had Lab 4 support, but its classifier wasn’t updated. After a new release with the correct classifier, it immediately surfaced as one of the most popular Lab 4 extensions (right after jupyterlab-pygments, which ships by default with Lab).
- Missing repository URLs on PyPI are also common, which makes it hard to map to GitHub and pull social/health signals.I’ve started reaching out to extension authors and opening small PRs to add/clean up Trove classifiers and repo links. If you maintain an extension and notice something off, I’m very happy to sync on fixes.
- The ecosystem is growing (and experimenting) Just before JupyterCon we crossed the 600 JupyterLab extensions mark; as of today we’re already at 626. A lot of the recent additions are co-created with AI tools and helpers, which matches the feeling that people are using extensions as a fast way to explore ideas or prototype solutions. Some of these patterns might be good candidates to move into core / “batteries included” over time once they stabilize.
Coming next
I will be trying to classify all of the extensions next to get the idea which types of extensions are being created and used more frequently.
If you have thoughts on ecosystem metrics (what you’d like to see on a “state of JupyterLab extensions” page) or want to help sanity-check categories/metadata, I’d love to hear from you.
4 Likes
