Install kernel without requiring users to install jupyter

[DonJayamanne]

Thanks for the great Jupiter kernel Is it possible to perhaps consider creating an installer that doesn’t depend on the Jupyter cli

Installing the kernel is basically just a matter of creating a folder in a predefined location with some files (in the past I created a vscode extension that did just this for the typescript kernel)

perhaps this can be part of the vscode extension? A vscode command to install the kernel (by creating the files instead of using the Jupiter cli)

this would benefit users of vscode and tools wanting to use this kernel

Else a node/deno developer now needs to install python to try deno in notebooks

[bartlomieju]

Hey @DonJayamanne we can certainly do that - out of curiosity does the VSCode extension not depend on actual jupyter Python package?

Do you happen to have a list of suggested locations we should try installing kernel to?

[DonJayamanne]

VSCode extension not depend on actual jupyter Python package?

that’s right, vscode does not We start kernels by spawning the process manually and communicating over zmq The kernelspec.json contains the cli and that’s what’s used

So connecting to deno can be done without Jupyter/python in vscode

python is only required for Python kernels

[bartlomieju]

Got it, very interesting. @rgbkrk any thoughts on this? This seems like a good idea, but I'm not sure where we should install the kernelspec in such case. Should we just accept --path flag (or default to last arg) deno jupyter --install <path_to_put_kernel_spec_to>

[rgbkrk]

Having it built in is great, I think I'm just traumatized by all the varied options we allow in Jupyter for where to install kernelspecs. I think we can just install to the user directory and expand what we provide over time if needed.

[rgbkrk]

These are the locations to provide per platform: https://jupyter-client.readthedocs.io/en/stable/kernels.html#kernel-specs

[zph]

I also run into wanting control over installing deno's jupyter kernel without relying on jupyter being on the path in a circumstance where jupyter is installed wrapped in another program. In that case jupyter is not on the PATH.

A way to allow this behavior without requiring the hard coupling of deno<>jupyter paths as @rgbkrk called out, is that we allow users to specify their own paths. It would be an advanced feature via an optional cli flag --directory.

I'll put up a PR for this capability.

[DonJayamanne]

called out, is that we allow users to specify their own path

I think the suggestion was that the CLI would automatically determine the location instead of having the user to provide this path

[rgbkrk]

I've been working on a Rust library for interfacing with Jupyter kernels, called runtimelib. With it, we can drop the need for a globally available jupyter: https://github.com/runtimed/runtimed/blob/main/runtimelib/src/jupyter/dirs.rs

@bartlomieju I'd love to chat more about this

[DonJayamanne]

Personally I'd prefer something like this https://crates.io/crates/evcxr_jupyter I do not have to know anything about the paths at all Given the fact that the paths are documented here, https://jupyter-client.readthedocs.io/en/stable/kernels.html#kernel-specs I think its simpler (IMHO) to just create the files in those directories as Jupyter is bound to find them.

Please note, I'm happy to contribute as well,

[bartlomieju]

@DonJayamanne I think we might want to close this issue now. Please try deno jupyter --install again. With recent change @rgbkrk did it works transparently and installs kernel to a proper directory.