-
-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
Move language info from kernelspec to kernel_info_reply #6793
Conversation
+1, seem reasonable. |
+1 as a kernel provider. |
Looks good to this kernel provider. Should anything happen if you load the notebook with the associated kernel, and the language_info details don't match exactly? I understand that this isn't a set of "dependencies" but just wondering how we can better support "reproducible results"... |
When the kernel starts, the language info from that kernel will replace |
@takluyver I understand. But my point is that if a notebook was created under kernel Language X version 1.0, and you open it up with kernel Language X version 16.5, then should something happen? Possibilities: a log warning, a dialog warning, etc. It could also be the case when then notebook is opened and the kernel is asked for kernel_info, the server could provide the cached kernel_info so that some handshaking could happen. For example, the kernel_info could respond with the equivalent of "Sorry: Your are trying to run a Language X version 1.0 notebook with a Language X version 16.5 kernel. Please see this website... for info on updating your notebook." |
I don't really see how using a later version of the same kernel would be a |
So Python 2 and Python 3 have exactly this problem, and you solved it by making a kernel for each, that can run side-by-side. So, looking forward, language kernel designers should think how this will work if there are backward-incompatible changes in their language or libraries. Ok, fair enough. Just making sure that this won't create chaos as languages continue to change. Thanks! |
I got a couple of +1s on this, so I'm going to merge it tomorrow unless anyone wants more time to review it. |
Similar problem is visible in IScala, where to support Scala 2.10 and 2.11 (binary incompatible), you have to compile IScala twice producing 2.10 and 2.11 kernels ( |
@takluyver, this is a very desired change, +1. Perhaps in future this could be extended, e.g. allowing kernels to provide their own syntax modes for CodeMirror. |
You will be able to do so with custom.js that register a mode for codemirror (julia do that) . But in the end modes should be sent upstream to codemirror repo itself. |
Move language info from kernelspec to kernel_info_reply
Move language info from kernelspec to kernel_info_reply
From #6776, and discussion from dev meeting yesterday.
This reduces kernelspecs to just names and the necessary information to launch a kernel. Information about the kernel language is now obtained by making a kernel_info_reply. It is still stored in notebook metadata, now under a
language_info
key, so that we can render notebooks correctly without requiring the kernel.In the notebook, we were already making a kernel_info_request whenever we connected to a kernel, but discarding the result; the result is now stored in JS as
kernel.info_reply
, and used to update the codemirror mode and the notebook metadata.