-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Displaying Jupyter Info in Kernel Selector #9
Comments
Yes the kernel selectors can certainly be improved. As I mostly just connect to the most recently started kernel it is not as big a problem for me. |
FYI, in Jupyter Notebook there's an API to get kernel specs. It listed all kernel name, language, etc. I didn't have to manually write a low-level script to achieve this. |
If I'm not mistaken, Kernelspec and kernel have distinct roles in Jupyter Notebook. Kernelspec is used to specify the language kernel used in Jupyter Notebook, while kernel is the actual program that executes the code. Kernelspec configures the kernel, while kernel executes the code. Jupyter Notebook attaches a kernel to each file we open, in order to connect them, we should use the kernel file in the runtime directory. However, the tricky thing is that the kernel file only records how we connect to it and doesn't tell us the specific kernelspec. In fact, it doesn't know because that can be modified by accessing the "Change Kernel" option in the Kernel menu. But Jupyter notebook did know, so I was wondering whether Jupyter Notebook provides this API. Do you happen to have any insights on this matter since perhaps no one has gone as far as you on the frontend API, based on this discussion jupyter/notebook#6307. |
I've used the javascript API on notebook to get the kernel specs, and passed that over to Python and parsed the dictionary data. You can refer to the Lua API section in the readme. There might be a python wrapper for this as well in notebook, but it could also be notebook-specific and not Jupyter kernel in general. If you find this API in python, then you can see how they implemented it (I assume using |
Oh yes I remembered going down this path once and when I couldn't execute those javascript magic in jupyter console I gave up. |
Thank you for your response. Your insights have been inspiring, and I appreciate them greatly. I will continue to delve deeper into the JavaScript API of the notebook. |
https://github.com/jupyter/jupyter_console Not sure if this works correctly. But it seems like it has a command |
My previous description may not have been clear enough, and I have now tried to correct it as much as possible. I apologize for any misunderstandings that may have arisen. |
The Jupyter Notebook file (ipynb) contains the kernel info (but I don't think the kernel ID because it can be always different). Maybe you can match this info with the running kernels. |
So my PR jupyter/jupyter_client#953 has been merged and release, I guess this can be implemented easily now. Also notebook v7 is coming, do you have plans to support it @lkhphuc @kiyoon ? |
@fecet If you mean Jupynium, from the last time I tested Notebook v7 alpha, there were no obvious way to interact with it using front-end only. If they support this, it becomes less annoying to write and I'm willing to re-write it. |
It's a shame that we can't use notebook v7 with jupynium. Perhaps we could submit an enhancement request for that so they can discuss it in their weekly meeting (if you'd like, of course). I tried it last time, and their response was very prompt. |
In the current "select a kernel" telescope, the kernel only displays its file name, making it difficult for people to find the kernel they want. Since most people open kernels through Jupyter Notebook, it would be helpful to include Jupyter Notebook information, such as the file name and kernelspec name. To be more clear, I want something like:
This may not be a simple task since Jupyter Notebook does not seem to provide a corresponding interface. The solution I am currently considering is to use
jupyter_client
to connect to each kernel and send codes to retrieve this information, look likeThis approach seems unnecessarily complex and requires some waiting time for kernel response. Do you think this is a useful feature, and do you have any better ideas?
The text was updated successfully, but these errors were encountered: