Monkeypatching jupyter_client.kernelspec

[mcg1969]

This is an idea that up with trying to resolve issues like #77.

The way nb_conda_kernels currently works is to add a configuration setting to jupyter_notebook_config.json that tells the notebook application to use an alternate kernel spec manager. Unfortunately, this means that it will only work for applications which respect this configuration, and that is only notebook, not nbconvert, not console, and so forth. Even jupyter kernelspec list doesn't work with nb_conda_kernels.=

What I've done here is create a new approach, which is effectively to patch the kernelspec.py file. The patch attempts to import nb_conda_kernels.manager, and if it succeeds, replaces KernelSpecManger with its subclass CondaKernelSpecManager.

Is this kosher? Well, no. Does it work? Seems to.

Currently, I don't have this configured to work by default; it has to be manually enabled. Fortunately, enabling is simple: in the environment where nb_conda_kernels is installed, type

python -m nb_conda_kernels patch

It tries to be very safe about the file modification itself. For one thing, the modification involves a simple append to the original file. Furthermore, the modification is first performed in a temporary file, and a multiple verifications are performed on the result; and only if those verifications pass, the file is moved into place.

An easy functional check to see if the patch is successful is to run

jupyter kernelspec list

after the patch is applied. It should see all of the same kernels that notebooks can.

[mcg1969]

I'm well aware that newer versions of the jupyter_client module are going to provide a more elegant method for allowing kernel providers to supply kernelspecs, rendering this approach obsolete. But I do think this will be helpful for at least awhile.

See this documentation for a description of this proposed new approach.

[mcg1969]

Not pursuing this anymore, will revisit afresh if there is time.