# jupyterlab-variableinspector: a variables panel for JupyterLab > The jupyterlab-variableinspector extension adds a side panel to JupyterLab that lists the variables in the current kernel with their values, and can show matrices in a data grid and render Jupyter widgets inline. Its own documentation warns that large frames can slow the browser down, because every value has to cross the kernel to front end boundary. **jupyterlab-contrib/jupyterlab-variableInspector** — Variable Inspector extension for Jupyterlab - Repository: https://github.com/jupyterlab-contrib/jupyterlab-variableInspector - Stars: 1,164 · Forks: 99 - Language: TypeScript - License: BSD-3-Clause - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/jupyterlab-contrib-jupyterlab-variableinspector ## A panel for the namespace you already have The jupyterlab-variableinspector extension is described as a JupyterLab extension that shows currently used variables and their values, and the whole product is that one sentence. What it does is narrow and useful. It opens a side panel in JupyterLab, and inside it you see the variables in the current kernel together with their values, and you can inspect them for both consoles and notebooks. The point of the tool is not that it can show a variable, since a notebook cell can always print one, but that it shows all of them at once without disturbing the cell you are in. The extension is prebuilt and distributed as a Python package, with the npm package name @lckr/jupyterlab_variableinspector and the PyPI name lckr_jupyterlab_variableinspector. It is BSD-3-Clause licensed, and the extension status badge marks it as ready to be used. The primary language is TypeScript, which is the front end, since the panel itself is a JupyterLab extension and the TypeScript build produces the labextension assets. The repository is under the jupyterlab-contrib organisation, which is the community group for JupyterLab extensions rather than the JupyterLab project itself, and the author is listed as lckr. The last push to the repository was on 2026-04-17, and the most recent published release is v3.2.4 from 2024-09-05, following v3.2.3 and v3.2.2 in the same week, so the published version and the working tree have diverged in time. ## The cost is in the kernel to browser boundary The section titled How it Works is short and it is the most important part of the documentation. In order to allow variable inspection, all content that is displayed first has to be sent from the kernel to the front end. The consequence follows directly: opening large data frames with the data grid viewer can dramatically increase your occupied memory and significantly slow down your browser. The documentation says to use it at your own risk. That is the honest trade of the extension, and it is worth understanding rather than just accepting. A kernel holds a DataFrame in memory, and the notebook front end holds the rendered output. When you expand a variable in the inspector, the value is serialised and sent across the kernel to browser channel, and the browser now holds a second copy of that data. This is why the feature list says the matrix inspection might not work for large matrices. It is a rendering limit, not a correctness one, and it depends on the shape of the data rather than its size alone, since a wide frame of many small cells can be worse than a tall frame of few large ones. The other two features do not have this problem in the same way. Inline interactive inspection of Jupyter widgets is limited to what a widget renders, which is a small tree of model values, and the widget display is the one feature that does not depend on pandas and numpy being present. ## What it takes to get each feature working The requirements are per feature rather than global, which is worth reading as a table. For the extension itself, JupyterLab 3.0 or higher is required. The Python functionality needs pandas and numpy for matrix inspection, pyspark for Spark support, tensorflow and keras to allow inspection of TensorFlow objects, and torch for PyTorch support. The R functionality needs the repr library. The ipywidgets functionality needs ipywidgets, which the documentation says can be installed with pip install ipywidgets. The language coverage is stated as uneven. The extension currently targets Python as the main language but also supports R and scala via the almond kernel, with different levels of feature completeness. That phrase is doing real work, because a language kernel that does not use the same introspection hooks will return less, and the panel will show a subset. The matrix viewer is a distinct feature from the value list, and it is the one that depends on pandas and numpy specifically rather than on Python alone. The TensorFlow, Keras, PyTorch, and Spark requirements are the same kind of thing: they enable the inspector to recognise and expand the objects those libraries create, and without the library installed the variable still appears, it just shows as an opaque object rather than a structure you can walk into. ## Installing the prebuilt extension The prebuilt extension is a single pip install, and the package name on PyPI is the underscore form: ```bash pip install lckr_jupyterlab_variableinspector ``` Removing it is the mirror image of that: ```bash pip uninstall lckr_jupyterlab_variableinspector ``` The package is a prebuilt JupyterLab extension, which the project classifiers confirm with the Framework:: Jupyter:: JupyterLab:: Extensions and Framework:: Jupyter:: JupyterLab:: Extensions:: Prebuilt classifiers. The build configuration shows what that means in practice. The Python package has no runtime dependencies of its own, the version and the metadata fields are pulled from the NodeJS package.json through a hatch nodejs version source, and the labextension assets are shipped as shared data into share/jupyter/labextensions/@lckr/jupyterlab_variableinspector, with the install.json file placed alongside so the front end can find the extension. The build system is hatchling with the jupyter-builder hook, which is what runs the TypeScript build during packaging. The schema/ directory at the top level holds the setting schemas, and the style/ directory holds the CSS, with the package files list showing that both lib/ and style/ are published along with style/index.js. There is a Binder badge in the README, and a binder/ directory in the repository, so you can open the extension in a hosted JupyterLab without installing anything locally. That is the fastest way to decide whether the panel is worth having in your own setup. ## The development install, and the watch loop The development path needs NodeJS to build the extension package, and the README uses jlpm, which is JupyterLab's pinned version of yarn that ships with JupyterLab, while noting that yarn or npm can be used in its place. The sequence for a development install is four commands: ```bash # Clone the repo to your local environment # Change directory to the lckr_jupyterlab_variableinspector directory # Install package in development mode pip install -e "." # Link your development version of the extension with JupyterLab jupyter labextension develop . --overwrite # Rebuild extension Typescript source after making changes jlpm build ``` The jupyter labextension develop step is what makes the link between your checkout and the running JupyterLab, and the --overwrite flag is there because the link already exists if you have installed before. The watch loop is the part that makes extension development bearable. You can watch the source directory and run JupyterLab at the same time in different terminals, and every saved change is immediately built locally and available in your running JupyterLab after a refresh, with a wait of several seconds for the rebuild. ```bash # Watch the source directory in one terminal, automatically rebuilding when needed jlpm watch # Run JupyterLab in another terminal jupyter lab ``` Source maps are generated by default to make debugging in the browser dev tools easier, and the documentation notes that to also generate source maps for the JupyterLab core extensions you can run jupyter lab build --minimize=False. The development uninstall has one extra step, because a develop install leaves a symlink behind. You uninstall the package, then run jupyter labextension list to find where the labextensions folder is, and remove the symlink named @lckr/jupyterlab_variableinspector inside it. ## Two test layers, and the packaging step The extension has two distinct test layers, which is a good sign for a front end project that has to talk to a kernel. The front end tests use Jest, and the commands are jlpm followed by jlpm test. The integration tests, described as user level tests, use Playwright, with the JupyterLab helper Galata handling the testing of the extension inside JupyterLab itself. The Galata detail matters, because Playwright on its own would have to drive a JupyterLab start-up, and Galata is the JupyterLab helper used to handle testing the extension inside JupyterLab. The integration test material lives in the ui-tests/ directory with its own README, and the repository also holds a CHANGELOG.md and a RELEASE.md that documents the packaging process, plus a.copier-answers.yml file, which indicates the project template itself is managed with Copier. The npm scripts in the package manifest show the layering of the build. The default build is jlpm build:lib followed by jlpm build:labextension:dev, so the TypeScript library is compiled with source maps first and then the labextension is built in development mode. The production build is clean, then a TypeScript compile without source maps, then jupyter labextension build, and there is a separate clean:labextension target that removes the built labextension directory and the generated _version.py. That separation between the library build and the labextension build is worth noting, because the two artifacts serve different consumers. The compiled lib/ is the extension's own module code, and the labextension directory is what JupyterLab actually loads as a prebuilt extension. ## Conclusion Adopt jupyterlab-variableinspector if you work in JupyterLab and keep losing track of what is in your namespace, especially when you use pandas frames or ipywidgets. Do not adopt it if you routinely open very large frames, because the documentation says the data has to be sent to the front end and that it will slow the browser down. Verify first that your JupyterLab is version 3.0 or newer, since the README requires it. ## FAQ ### How do I install the JupyterLab variable inspector extension? Run pip install lckr_jupyterlab_variableinspector, and remove it with pip uninstall lckr_jupyterlab_variableinspector. It is a prebuilt extension, and the repository also has a Binder badge so you can try it in a hosted JupyterLab without installing it. ### What is the main limitation of the variable inspector? Everything shown has to be sent from the kernel to the front end, so opening large data frames with the data grid viewer can dramatically increase occupied memory and significantly slow down the browser. The documentation says to use it at your own risk, and the matrix inspection might not work for large matrices. ### Which languages does the variable inspector support? Python is the main target, with different levels of feature completeness for R and for scala via the almond kernel. The Python feature set needs pandas and numpy for matrix inspection, pyspark for Spark, tensorflow and keras for TensorFlow objects, and torch for PyTorch support. ### How do I set up a development install of the extension? Install the package in editable mode with pip install -e ".", link it to JupyterLab with jupyter labextension develop . --overwrite, and rebuild the TypeScript source with jlpm build. NodeJS is required to build the package, and jlpm can be replaced by yarn or npm. ### How are the variable inspector tests run? Front end tests use Jest and are run with jlpm and jlpm test. Integration tests, described as user level tests, use Playwright with the JupyterLab helper Galata, and the details are in the ui-tests README. ## Sources - [Issues](https://github.com/jupyterlab-contrib/jupyterlab-variableInspector/issues) - [jupyterlab-contrib/jupyterlab-variableInspector on GitHub](https://github.com/jupyterlab-contrib/jupyterlab-variableInspector) - [License: BSD-3-Clause](https://github.com/jupyterlab-contrib/jupyterlab-variableInspector/blob/main/LICENSE) - [README](https://github.com/jupyterlab-contrib/jupyterlab-variableInspector/blob/main/README.md) - [Releases](https://github.com/jupyterlab-contrib/jupyterlab-variableInspector/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jupyterlab-contrib-jupyterlab-variableinspector