nebari-dev / nebari-dev/data-science-pack
Gate Kernels on Install Status
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 5
- Forks
- 7
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 13
Description
Summary
When the nebi server adopts the explicit-install model (see nebari-dev/nebi#438), workspaces default to locked-but-not-installed. nb_nebi_kernels must stop discovering kernels from uninstalled workspaces. One change: pass --installed to the local nebi workspace list call. No other touchpoints in this chart are affected.
Goals
nb_nebi_kernelsonly discovers kernels from workspaces that are installed on disk (.pixi/envs/present).- The
nb_nebi_kernelsversion pin in the jupyterlab image is bumped to the release containing the fix.
Non-Goals
- Changes to the jhub-apps environment selector (
03-nebi-envs.py). It lists workspaces from the nebi server API for use in app pods. App pods always install into a fresh directory regardless of the server's install status, so filtering is unnecessary. - Changes to the nebi serve configuration (
images/nebi/jupyter_server_config.py). The nebi binary handles install status internally. - Changes to workspace PVC setup. The binary discovers install status from disk via the existing PVC mount.
Background / Motivation
The nebi server is changing from implicit install (run pixi install on every workspace creation/update) to explicit install (pixi lock only; install is a user action). After this change:
nebi workspace list --jsonreturns all workspaces regardless of install status. A--installedflag filters to installed-only.- Workspaces without
.pixi/envs/are locked but not runnable.
nb_nebi_kernels calls nebi workspace list --json without --installed, creating kernel specs for every locally-tracked workspace. Launching a kernel against an uninstalled workspace would trigger an implicit pixi install with no progress indication — the exact UX problem the nebi change was designed to eliminate.
The main JupyterLab pod gets workspaces through the persistent workspace PVC at /var/lib/nebi/workspaces. nb_nebi_kernels discovers kernels from these local workspaces and must only surface installed ones.
Design
1. Kernel discovery: pass --installed to nebi workspace list
Repo: nebari-dev/nb-nebi-kernels
File: src/nb_nebi_kernels/discovery.py
Change the subprocess call in discover_workspaces():
# Before
["nebi", "workspace", "list", "--json"]
# After
["nebi", "workspace", "list", "--json", "--installed"]
No other changes to nb_nebi_kernels. The --installed flag is part of the nebi CLI change in the same nebi release.
2. Version bump
File: images/jupyterlab/pixi.toml
Bump nb_nebi_kernels from ==0.1 to the release containing the --installed fix (e.g., ==0.2). The exact version depends on the release tag chosen for the nb_nebi_kernels change.
Tradeoffs & Risks
| Tradeoff | Mitigation |
|---|---|
The local nebi binary is part of this chart (copied via init container from nebi.image). The nebi workspace list --installed flag must exist in that image. |
The nebi image tag is pinned in values.yaml. When bumped to include the --installed feature, the local CLI and nb_nebi_kernels change ship atomically. |
The nb_nebi_kernels change is in a separate repo, creating a two-repo release dependency. |
Both repos are under project control. The nb_nebi_kernels release must land before the data-science-pack version bump. |
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with src/nb_nebi_kernels/discovery.py in nb-nebi-kernels and verify the released version that supports the --installed workspace-list option. Then update the nb_nebi_kernels pin in images/jupyterlab/pixi.toml and confirm the pinned nebi image tag provides the matching CLI flag. Done means kernel discovery excludes uninstalled workspaces and both dependency versions are compatible.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- build-system, tooling
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 65/100