Bootstrapping a custom kernel

[Quafadas]

I've gotten scala working using the https://almond.sh kernel. What I'd like to be able to to do, is contribute a bootstrap to the metals project (the project providing scala lsp support) with the hope that others may also be able to to enjoy notebook support.

I'm not sure if it's tractable... would it be it possible to layout (are there docs?) how VS Code discovers (and starts?) kernels?
Does a kernel need to be registered somehow? A local juypterlab install required?

[IanMatthewHuff]

@Quafadas If this helps at all we do respect global jupyter paths for where we pick up kernelspecs.

https://jupyter-client.readthedocs.io/en/latest/kernels.html#kernel-specs

You don't need to have Jupyter installed locally, but it might help for testing. And anything that jupyter kernelspec list can see we should be able to locate and start in VS Code.

[Quafadas]

Thanks, I think that's exactly the answer I needed.

[IanMatthewHuff]

@Quafadas Sounds good. I can't promise what we can explicitly do to help support what you are working on. But if you are running into hitches you can always post back here and we (or other users) might be able to help.

[Quafadas]

@IanMatthewHuff A quick follow up question if you had a moment...

Here's the issue where I?m documenting my experiments. No need to read it as there's a lot of fluff, but here for posterity.

scalameta/metals-feature-requests#236

The Almond "main" class appears to make allowance for "installation". As far as I can tell, that sets everything up to work with VSCode.

The problem is, that it needs to know how to be launched... and in isolation, almond doesn't contain many of the classes it needs - in other words, I need to find a way to start it in an environment with the right class path. I'm thinking there are two solutions;

1. As I'm doing this inside the LSP server, I think I can find the class paths and a project name, and install 1 kernel per project. The installation script would record the class path for that project
2. Try to have a "global kernel" per scala version, and try to update the .env file with the project classpath in each project per this discussion.

#10151

I'm leaning toward setting up a kernel per project. Do you see a big advantage / disadvantage of either strategy? If not that's fine... I'll experiment!

[IanMatthewHuff]

@Quafadas Sorry I was out of the office for a bit and missed this come in. Might be that you are already past this. I don't know that there is a "wrong" answer between those two choices. From my Jupyter knowledge option #2 lines up more with how I'd initially regard it. If these kernels are "global" you might end up with a very clogged kernel picker as they would all be available as options (kinda depends on the number of projects you expect to have) if you went with a kernel per project. I'd consider a kernel an execution environment so having one of those per Scala version and updating and env per project is what I would try first. But I don't believe the other option is wrong.