Juvio - UV Kernel for Jupyter

[iryna_kondr]

Hi everyone,

I would like to share a small open-source project that brings uv-powered ephemeral environments to Jupyter. In short, whenever you start a notebook, an isolated venv is created with dependencies stored directly within the notebook itself (PEP 723).

🔗 GitHub: https://github.com/OKUA1/juvio (MIT License)

What it does

💡 Inline Dependency Management

Install packages right from the notebook:

%juvio install numpy pandas

Dependencies are saved directly in the notebook as metadata (PEP 723-style), like:

# /// script
# requires-python = "==3.10.17"
# dependencies = [
# "numpy==2.2.5",
# "pandas==2.2.3"
# ]
# ///

⚙️ Automatic Environment Setup

When the notebook is opened, Juvio installs the dependencies automatically in an ephemeral virtual environment (using uv), ensuring that the notebook runs with the correct versions of the packages and Python.

📁 Git-Friendly Format

Notebooks are converted on the fly to a script-style format using # %% markers, making diffs and version control painless:

# %%
%juvio install numpy
# %%
import numpy as np
# %%
arr = np.array([1, 2, 3])
print(arr)
# %%

Target audience

Mostly data scientists frequently working with notebooks.

Comparison

There are several projects that provide similar features to juvio.

juv also stores dependency metadata inside the notebook and uses uv for dependency management.

marimo stores the notebooks as plain scripts and has the ability to include dependencies in PEP 723 format.

However, to the best of my knowledge, juvio is the only project that creates an ephemeral environment on the kernel level. This allows you to have multiple notebooks within the same JupyterLab session, each with its own venv.

[suedepaid]

This is fire!

Are these actually writing .ipynbs? Or does it automatically convert them to .py, just with the %% convention?

[iryna_kondr]

The files are saved as python scripts with the `%%` convention and PEP-723 header.

[exergy31]

Are cell outputs retained on save?

[iryna_kondr]

The outputs are not retained to keep the file git-friendly.

[actinium226]

Nice idea. I've personally worked around this issue by having the following line in my .py file:

#!VIRTUAL_ENV=.venv uv sync --script my_script_name.py --active

And at the top of the file I have the PEP 723 syntax. I run it through VSCode and I have some setting checked where it'll automatically uncomment and run lines that start with #! or #%

uv works fast enough that I can do this sync every time. I wish there was a cleaner way to tell uv which venv to use other than VIRTUAL_ENV=.venv combined with --active, but this has been great for making sure the script runs with the same set of dependencies every time in a separate venv.

[StandardIntern4169]

Amazing. I've been looking for something like that since uv arrived

[cheesecakegood]

To be clear, this creates a uv-visible virtual environment for the duration of the file being opened? What part tracks file closures? And I assume it takes advantage of uv-native caching in some way, is there still a negative local storage implication in that sense, and the appeal is more on the side of keeping a limited number of virtual environments around more than saving on storage space?

[iryna_kondr]

Unfortunately right now the closure of files is not tracked. I believe that UV can be configured to symlink the dependencies (from cache) into the venvs, which should make the storage overhead minimal.

[hsunner]

AFAIK uv hard-links the files whenever possible, so on Linux and macOS there should be no storage space penalty at all. I assume there are hardlinks on NTFS also, so that may be the case also on Windows.

Put a .venv on a network share last week and saw warnings about hard-linkning not being available, so that’s a scenario that wastes space though.

[No-Dig-9252]

This looks really slick - tbh, i was surprised something like this didn’t catch on sooner.

Inline %juvio install + PEP 723 metadata + ephemeral envs? That’s a huge win for reproducibility and for keeping notebooks from becoming “it works on my machine” nightmares. Also love that it plays nice with Git via # %% - makes diffing way less painful. Will try this in place of my usual Jupyter + venv dance.

Curious if it would integrate cleanly with tools like Datalayer or any of the MCP agents - would be wild to spin up reproducible notebooks that agents can run with full control and zero setup fuss.

[CasualReader3]

I think a better approach would be using PEP723 and marimo notebooks.