how about

{
  jupyterLib.mkKernels = {
    python = {
      # the env should be an individual python env
      env = pkgs.python3.withPackages [ ];
      # if env == {}, then env = pkgs.python3.withPackages (ps: ps withPackages) ++ [python.pkgs.ipykernel]);
      withPackages = [];
      override = {
        ...
      };
    };
    haskell = {
      # env = pkgs.haskellPackages.ghcWithPackages (p: with p; [ ihaskell ]);
      # if env == {}, then env = pkgs.haskellPackages.ghcWithPackages (p: with p; [ ihaskell ]) ++ ghcWithPackages p);
      ghcWithPackages = p: [ p.ihaskell ];
      override = {
        display_name = "Custom Haskell";
      };
    };
    ...
  };
}

In reply to @p14:matrix.org
g'day. I just started trying to use jupyter-notebook, but discovered that in nixos somewhere between nixpkgs/690e58e11de69953a1e76d0b9cc5f8caee63badd and present, keyboard navigation of cells in command mode is broken. (Up/down arrow, j/k should move up/down cells but nothing happens).

I've been trying to isolate the issue: if I take a recent nixpkgs commit and inject old jupyter-notebook, that breaks it, so it's not jupyter/notebook versions that's causing the breakage but presumably some other package or incompatibilities between them. Therefore I suspect this is not a jupyter bug but a nixpkgs bug. Any thoughts?

In reply to @gtrunsec:matrix.org
I don't mind rewriting a more powerful jupyenv as a new project, but I hope the current nixpkgs.jupyter can exist as much as possible as a library. If there's a plan for that project, then I would just need to focus on the integration of the data-science env and other Nix ecosystems

this sounds like a potentially larger scope than what i had in mind.

i thought we were just trying to solve the problem of "user wants to spin up Jupyterlab/notebook/console with some set of kernels." AFAICT this is roughly what jupyenv is for too. i gather you want to be able to do things like override the Python environment with one derived from poetry2nix. i think we can probably support this without too much trouble, just by making sure that the components that go into each kernel are easy to override.

if there's more to this then maybe a design doc is called for.

i think we can probably support this without too much trouble, just by making sure that the components that go into each kernel are easy to override.

right, as I mentioned earlier. For me, it is sufficient to override each kernel individually and incorporate most of the kernel packages into the nixpkgs for the maintenance aspect. As for other tasks, I wii have a plan to develop a more robust jupyenv to fulfill those requirements.

i think we can probably support this without too much trouble, just by making sure that the components that go into each kernel are easy to override.

right, as I mentioned earlier. For me, it is sufficient to override each kernel individually and incorporate most of the kernel packages(ocaml/js,psql,zsh, etc) into the nixpkgs for the maintenance aspect. As for other tasks, I wii have a plan to develop a more robust jupyenv to fulfill those requirements.

i think we can probably support this without too much trouble, just by making sure that the components that go into each kernel are easy to override.

right, as I mentioned earlier. For me, it is sufficient to override each kernel individually and incorporate most of the kernels package(ocaml/js,psql,zsh, etc) into the nixpkgs for the maintenance aspect. As for other tasks, I wii have a plan to develop a more robust jupyenv to fulfill those requirements.

In reply to @p14:matrix.org
g'day. I just started trying to use jupyter-notebook, but discovered that in nixos somewhere between nixpkgs/690e58e11de69953a1e76d0b9cc5f8caee63badd and present, keyboard navigation of cells in command mode is broken. (Up/down arrow, j/k should move up/down cells but nothing happens).

I've been trying to isolate the issue: if I take a recent nixpkgs commit and inject old jupyter-notebook, that breaks it, so it's not jupyter/notebook versions that's causing the breakage but presumably some other package or incompatibilities between them. Therefore I suspect this is not a jupyter bug but a nixpkgs bug. Any thoughts?

I'm still not sure what's causing the problem. git bisect says this commit caused it.

first bad commit: [39bd27fd2e71dbcf87efdb675500496fa3cd2633] python311Packages.jupyterlab: 4.0.6 -> 4.0.9

In reply to @p14:matrix.org
g'day. I just started trying to use jupyter-notebook, but discovered that in nixos somewhere between nixpkgs/690e58e11de69953a1e76d0b9cc5f8caee63badd and present, keyboard navigation of cells in command mode is broken. (Up/down arrow, j/k should move up/down cells but nothing happens).

I've been trying to isolate the issue: if I take a recent nixpkgs commit and inject old jupyter-notebook, that breaks it, so it's not jupyter/notebook versions that's causing the breakage but presumably some other package or incompatibilities between them. Therefore I suspect this is not a jupyter bug but a nixpkgs bug. Any thoughts?

I'm still not sure what's causing the problem. git bisect says this commit caused it.

first bad commit: [39bd27fd2e71dbcf87efdb675500496fa3cd2633] python311Packages.jupyterlab: 4.0.6 -> 4.0.9

In reply to @natsukium:matrix.org

I'm still not sure what's causing the problem. git bisect says this commit caused it.

first bad commit: [39bd27fd2e71dbcf87efdb675500496fa3cd2633] python311Packages.jupyterlab: 4.0.6 -> 4.0.9

Thanks for the bisect, I can reproduce 39bd27fd2e71dbcf87efdb675500496fa3cd2633 as the first bad commit.

I can further elaborate that the issue appears between 4.0.6 and 4.0.7. I did that by taking that bad commit and overriding the src to acquire the 4.0.7 wheel.

In reply to @thomasjm:matrix.org
your diagnosis sounds right. could you file a Nixpkgs issue and tag the Jupyter team?

https://github.com/NixOS/nixpkgs/issues/280539

I tried for a couple of hours to figure out how to bisect jupyterlab-as-a-dependency-of-jupyter-notebook-in-developer-mode but didn't succeed unfortunately. Bisecting it as an ordinary dependency doesn't work because it just picks up the versions encoded in the package.json when they're eventually bumped.