# best-of-jupyter: a ranked index of 300 Jupyter projects, and how to read its scores > best-of-jupyter is a curated, automatically ranked list of 300 open source Jupyter Notebook, Lab and Hub projects, split into 13 categories and rebuilt weekly from GitHub and package manager metrics. It is a discovery index, not a package, and its ranking is a heuristic you should treat as a starting point. **ml-tooling/best-of-jupyter** — 🏆 A ranked list of awesome Jupyter Notebook, Hub and Lab projects (extensions, kernels, tools). Updated weekly. - Repository: https://github.com/ml-tooling/best-of-jupyter - Stars: 1,243 · Forks: 94 - Language: Unknown - License: CC-BY-SA-4.0 - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/ml-tooling-best-of-jupyter ## What best-of-jupyter actually is, and who it is for This is a list, not software. The repository holds a README, a projects.yaml file, a config/ directory, a history/ directory, a latest-changes.md changelog and a CONTRIBUTING.md. The README states the list contains 300 open source projects grouped into 13 categories, and that all projects are ranked by a project-quality score calculated from metrics collected from GitHub and different package managers. If you are choosing a JupyterLab extension, a kernel for a language the default stack does not cover, or a JupyterHub authenticator, this is a starting map. If you are looking for a library to import, you are in the wrong repository. The intended audience is narrow and technical: someone who already runs Jupyter and now has to pick among dozens of overlapping options. The categories reflect that. JupyterLab Extensions has 52 entries, Interactive Widgets and Visualization has 56, Jupyter Kernels has 43, JupyterHub Authenticators has 15. Those are the areas where the ecosystem fragments most, and where a ranked index saves the most time. The category names also tell you what the list refuses to do: it does not merge Notebook Environments, JupyterHub Spawners and Jupyter Components into one "infrastructure" bucket, because a spawner and a notebook environment are chosen at different moments by different people on the same team. ## How the quality score and the entry flags are produced Nothing here is hand-scored. The README says the project-quality score is calculated from metrics automatically collected from GitHub and different package managers. Each entry then exposes the raw inputs behind that number: contributor count from GitHub, fork count, issue count, the last update timestamp on the package manager, download count, and the number of dependent projects. A legend at the top of the README maps symbols to state: a chick for projects less than six months old, a sleeping mark for six months without activity, a skull for twelve months, up and down arrows for trending, a plus for recently added, and a warning symbol for things like a missing or risky licence. That design has a consequence worth naming. The score is a composite, and the list never publishes the weights. Two projects with the same medal can differ sharply on the inputs you care about. A project with a large download count and a stale package manager timestamp is a different bet from one with fewer downloads and a release last week. The entry format lets you see that, but only if you read the parenthetical metrics instead of the medal. My view: the medal is for scanning a 300-item page, and the metrics line is for deciding. Treating the medal as the answer inverts the tool. The flags carry a subtler problem. They are computed from the same collected data that feeds the score, so a project can be marked inactive while its upstream repository is busy, or look healthy because a package manager keeps serving downloads for a version nobody maintains. The README does not state how the thresholds were chosen or whether the legend is applied uniformly across all 13 categories. Two of the categories behave differently in practice: kernels and authenticators are small, slow-moving sets where a six-month gap is normal, while JupyterLab Extensions is volatile and a six-month gap there usually means the extension has been superseded. The same sleeping symbol means different things depending on which category you are reading. ## Installing nothing: cloning the list and using it as a data source There is no package to install. The list is consumed as a repository. The README's own example for the JupyterLab entry shows the clone form used throughout: ```bash git clone https://github.com/ml-tooling/best-of-jupyter ``` After cloning you get projects.yaml at the repository root, alongside config/ and history/. The README points contributors at that file directly, offering a link to edit projects.yaml on the main branch, and it accepts issues and pull requests. So the practical first use is not reading the README at all: it is reading the YAML, which is the structured form of the same data and is far easier to filter than a rendered page. The README also shows the per-project install commands it collects, for example the PyPI line for JupyterLab: ```bash pip install jupyterlab ``` and the Conda form for the same project: ```bash conda install -c conda-forge jupyterlab ``` The multi-user server appears with its own Docker form: ```bash docker pull jupyterhub/jupyterhub ``` Those commands are convenience pointers to the upstream projects, not instructions for this repository. The README does not document how projects.yaml is validated, what the schema of a project entry is, or how to run the update pipeline locally. If you want to contribute a project, the README's route is to edit projects.yaml or open an issue, and CONTRIBUTING.md is the file to read before you do. ## Weekly regeneration is the feature and the weak point The list carries a badge for release date and the release history shows a weekly cadence: 2026.08.13, 2026.08.20, 2026.08.27, with the last push to the repository on 2026-09-03. The README describes the list as updated weekly. That is a genuine advantage over a hand-curated awesome list, where entries rot silently and nobody notices that a linked project died two years ago. It is also where the list is least reliable. Automated metrics lag reality in both directions. A project that moved to a monorepo can show a stale package manager timestamp while development continues elsewhere. A project that publishes frequently but is effectively unmaintained can look healthy on download count. The list's own inactivity flags are derived from activity data, so they inherit the same lag: a project marked inactive is inactive according to the collected timestamps, which is a narrower claim than "abandoned". The README does not explain how a project is removed, how disputes over a score are resolved, or whether the score formula is versioned. For a 300-entry index that is a real gap, because the ranking is the product. There is a second-order effect on the changelog. latest-changes.md exists at the repository root, so a regular reader can see what moved between weekly builds. That is more useful than the score itself for one specific task: noticing that a project you already depend on has started trending down. It is less useful for anything requiring a stable identifier, because entries are re-ranked every week and a project's position is not a durable property you can cite. ## Where this list is the wrong tool Do not use it to decide whether a specific extension is compatible with your JupyterLab version. The entries carry install commands and metrics, not compatibility ranges. The README does not document a version matrix, and the category structure does not encode which JupyterLab major release an extension targets. Do not use it as a dependency source. There is no package, no lockfile and no API. If you want to pin a kernel or an authenticator, you pin the upstream project, and this repository only helps you find its name. Do not treat the ranking as a security or licence audit. The legend includes a warning symbol for a missing or risky licence, which is useful, but the README does not state that every entry has been licence-checked, and the repository's own licence is a separate matter from the licences of the 300 listed projects. Finally, if your question is "which notebook environment should I standardise on", the list will hand you JupyterLab, Jupyter, JupyterHub and Docker Stacks in the same category with no guidance on combining them. That is a decision the list deliberately does not make for you. One more boundary: the list is scoped to Jupyter. If your problem is general Python packaging, container orchestration or model serving, the Jupyter Kernels and JupyterHub Spawners categories will surface projects that touch those areas, but the list has no coverage of the surrounding tooling you would need to make them work together. ## Compared with an unranked awesome list The obvious alternative is a plain awesome-style list: same domain, same Markdown format, no scoring. The difference in approach is that best-of-jupyter derives its ordering from collected metrics and regenerates on a schedule, while a classic awesome list is ordered by human judgement and updated when someone opens a pull request. The ranked list scales to 300 entries without a maintainer reading all of them; the unranked list can encode context a score cannot, such as "this extension is the one that works with JupyterLab 4" or "this project is dormant but still the only option for X". Neither wins outright. The ranked list is better for breadth and for spotting projects you did not know existed. The unranked list is better when the ordering matters less than the annotation. A reasonable workflow is to use best-of-jupyter to build the candidate set from its 13 categories, then read the linked repositories for the context the score drops. The same comparison applies within the ranked family. The README links to best-of.org and to a guide for creating your own best-of list, so the ranking machinery is reusable across domains. That is a point in favour of the format and a caution about the content: a best-of list is only as good as the metric set it feeds on, and this one inherits whatever the GitHub and package manager APIs expose. ## Licence and the cost of keeping it current The repository is licensed CC-BY-SA-4.0, a content licence rather than a software licence. That fits what it is: a curated document and a YAML dataset. The practical implication is that reuse is governed by attribution and share-alike terms rather than by a permissive software grant, which matters if you intend to mirror the list, embed its data in a product, or republish a derivative ranking. The licence text in LICENSE is the authority; this is not legal advice and the terms should be read in full before redistribution. Maintenance cost sits with the maintainers, not the user, because the update is automated and weekly. The user's cost is the opposite: there is nothing to upgrade, but there is also nothing to pin. You cannot depend on the list being stable, since entries are re-scored and re-ordered every week. If you build tooling against projects.yaml, expect the file to change under you, and note that the README does not document a schema version for it. The README does invite contributions through issues and pull requests, so the practical upgrade path for a stale entry is a patch to projects.yaml rather than a version bump. ## Conclusion Use best-of-jupyter when you need to survey the Jupyter extension, kernel or authenticator space before committing to one, and treat its quality score as a filter rather than a verdict. Skip it if you want a maintained library, a versioned dependency, or install instructions for the projects themselves: the list carries clone, pip, conda, npm and docker commands per entry but no compatibility matrix. Before adopting anything it ranks, open the linked repository and check its own last commit date, because the list's flags are derived from activity data and the entry text is not a substitute for the upstream README. ## FAQ ### Is Jupyter Notebook outdated? The list does not make that claim. It carries both JupyterLab and the classic Jupyter notebook as separate entries in the Notebook Environments category, with JupyterLab ranked first in that category and the Jupyter notebook entry marked with a downward trend symbol. ### Is there something better than Jupyter notebooks? best-of-jupyter does not rank one environment above another as a blanket answer; it lists 16 projects in Notebook Environments and 56 in Interactive Widgets and Visualization. If you are looking for alternatives, that category is where the list puts them. ### Do AI engineers use Jupyter notebooks? The list does not address who uses notebooks. It does carry machine-learning and deep-learning topics and a Jupyter Kernels category with 43 projects, which indicates the ecosystem the list covers rather than the habits of any group. ## Sources - [Issues](https://github.com/ml-tooling/best-of-jupyter/issues) - [License: CC-BY-SA-4.0](https://github.com/ml-tooling/best-of-jupyter/blob/main/LICENSE) - [ml-tooling/best-of-jupyter on GitHub](https://github.com/ml-tooling/best-of-jupyter) - [README](https://github.com/ml-tooling/best-of-jupyter/blob/main/README.md) - [Releases](https://github.com/ml-tooling/best-of-jupyter/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ml-tooling-best-of-jupyter