Updating the Jupyter ecosystem on nixpkgs

Hi all,

I wanted to work a bit on updating the Jupyter ecosystem in nixpkgs and adding JupyterLite. I co-wrote the original jupyterWith package a long time ago before it became jupyEnv which seems currently stalled. The main argument for developing jupyterWith outside of nixpkgs was that, at the time, Jupyter extensions couldn’t be prebuilt and had to be dynamically downloaded, installed and built by Jupyter, an impure step that couldn’t end up in nixpkgs. This is different now, extensions can be prebuilt, and I’m willing to give it another try also because I got reinvolved with Jupyter for work reasons. But I’m fairly new to the built-in nixpkgs python infrastructure, having usually worked with tools like uv2nix, so please excuse some beginner questions.

Updating JupyterLab requires changing the build system to hatch which in turn requires updating hatchling which many other packages depend on … How do you deal with such updates? Are you running some global python packages test afterwards to check whether the update breaks anything else? Also, it seems such a web of dependencies will quickly open dependency hell. Any suggestions?

Also, any thoughts on treating Jupyter as a separate applications (with a pinned python package set that may be different from the official one) and giving it access to the latest Python ecosystem through the kernels?

7 Likes

i had some time during christmas 2 years ago and had started an effort towards improving that:

The only code contribution, I disagreed with one of the reviewer and lacked the energy/time to push forward and gave up jupyter.lib: init by teto · Pull Request #278315 · NixOS/nixpkgs · GitHub .
My belief is that several things can be done to improve the jupyter fondations in nixpkgs. Once you have that, pinning the ecosystem can be done in another repo/project but this time with a less alien project than jupyterWith.

1 Like

OK, I’ll have a look at that. @teto the original jupyterWith was just a simple function. It then was refactored/renamed and became overly complex (in my opinion. I wasn’t involved anymore at that point but it doesn’t matter). I stopped using it at that point. I’ll have a look at the PR you shared, thanks!

I’m curious, how would you do this: “pinning the ecosystem can be done in another repo/project”? We need to pin versions in nixpkgs anyway, correct?

I think that would be a good idea, there’s no reason it needs to be the same. IIRC we’ve suffered Jupyter breakages in the past due to routine Python package updates.

I’m another member of the Jupyter team, and I had laid out a bit of a design/implementation plan in this comment: Documentation: jupyter doc & API discussion · Issue #269331 · NixOS/nixpkgs · GitHub. And there was some further discussion in jupyter.lib: init by teto · Pull Request #278315 · NixOS/nixpkgs · GitHub.

Not sure if you’re up for working on overall API improvements but I’m happy to discuss this stuff.

1 Like