Repository: ipython/ipython

Issue:
When kernel is missing, notebook fails to load
Using master as of 0f92b92748b0dc07dd, I tried loading a notebook with a kernel I don't have configured (Python 3). Instead of getting the message indicating I should install it and at least being able to read the notebook, the popup said

```
Notebook failed to load
The error was:
TypeError: Cannot read property 'resources' of undefined
```

And the notebook didn't load at all.

This is obviously a hard blocker for release.



Discussion:
Yep, definitely need to fix this. Another failure route we should test when we do this is starting a notebook for a kernel that has a kernelspec, but not the actual kernel. I could easily imagine users ending up with kernelspecs for kernels that are no longer installed.

I get a slightly different error now, but still very cryptic.

An absolutely dead-minimalist patch is here:
https://github.com/ptone/ipython/compare/kernel-warn-ux?expand=1

In looking at @ellisonbg comment, I also went through and found several other failure modes that I documented for myself here:

https://docs.google.com/spreadsheets/d/1MnNEhgzJ3cGl-Um45fLvFoHouz04b4-LMEvlgSKu5zw/edit?usp=sharing

The "incomplete runtime" issue was very easy to hit initially - as I had IPython for python 3 in a virtualenv, but I imagine many people will use a boilerplate ipy3 spec that just as python3 as the executable.

In this case, python3 is a valid executable, but there is no IPython module available (or pyzmq).

In any failure mode - I guess there is a design decision as to how "editable" a notebook should be without a kernel.  Should a big grey overlay just go over the whole notebook? I guess that would be entirely counter to #4938 but would be friendlier to the "common case" of novices who don't pay enough attention to the kernel state indicator. An error should at least occur when executing a code cell with no valid kernel present.

Also another radical change (post 3.0 I would guess) would be to preflight the notebook from the homescreen instead of just being a link - and show such an error before a new tab is even open). [edit - again I guess this conflicts with the design for #4938]

Looking through https://github.com/ipython/ipython/issues?q=is%3Aissue+is%3Aopen+kernel+in%3Atitle

I don't see any super tightly coupled or duplicate issues to this one. Not sure how you want to split different failure modes into different issues, or just use this as a master issue.

> I imagine many people will use a boilerplate ipy3 spec that just as python3 as the executable.

Our hope is that people will install the IPython kernelspecs with `ipython kernelspec install-self`, which will create it with the full path to the current executable, which should know about IPython.


Resolving patch:
diff --git a/IPython/kernel/kernelspec.py b/IPython/kernel/kernelspec.py
--- a/IPython/kernel/kernelspec.py
+++ b/IPython/kernel/kernelspec.py
@@ -36,6 +36,7 @@ def _pythonfirst(s):
 class KernelSpec(HasTraits):
     argv = List()
     display_name = Unicode()
+    language = Unicode()
     env = Dict()
     resource_dir = Unicode()
     
@@ -54,6 +55,7 @@ def to_dict(self):
         d = dict(argv=self.argv,
                  env=self.env,
                  display_name=self.display_name,
+                 language=self.language,
                 )
 
         return d
@@ -109,8 +111,10 @@ def _native_kernel_dict(self):
         The native kernel is the kernel using the same Python runtime as this
         process. This will put its information in the user kernels directory.
         """
-        return {'argv': make_ipkernel_cmd(),
+        return {
+                'argv': make_ipkernel_cmd(),
                 'display_name': 'Python %i' % (3 if PY3 else 2),
+                'language': 'python',
                }
 
     @property


Test patch: