Move language info from kernelspec to kernel_info_reply

[takluyver]

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.

[Carreau]

+1, seem reasonable.

[blink1073]

+1 as a kernel provider.

[dsblank]

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"...

[takluyver]

When the kernel starts, the language info from that kernel will replace
that in notebook metadata. The idea is that updates to the kernel might add
or refine information, and the changes will take effect on existing
notebooks when they next have a running kernel.

[dsblank]

@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."

[takluyver]

I don't really see how using a later version of the same kernel would be a
problem. If the language or the kernel changes in a seriously incompatible
way, I would just give the kernel a different name, as we have already done
for Python 3. If this isn't sufficient for some reason, let's cross that
bridge when we come to it. I don't feel like there's a clear problem yet to
solve there.

[dsblank]

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!

[takluyver]

I got a couple of +1s on this, so I'm going to merge it tomorrow unless anyone wants more time to review it.

[mattpap]

So Python 2 and Python 3 have exactly this problem

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 (IScala_2.xx.jar).

[mattpap]

@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.

[Carreau]

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.