The Continued Existence of the Emacs IPython Notebook
This is a guest post by John, who initially sent it to our mailing list; we believe that it’s an interesting story, so we wanted to share it on here on the blog.
All,
After the recent, exciting announcement of the eminent JupyterCon, I was somewhat saddened to see no mention of the EIN, or the Emacs IPython Notebook, as an available client to the Jupyter notebook server. Drama queen that I am, I quickly wrote a note to Fernando, who patiently and kindly explained that not many were aware that this project still existed and that perhaps an announcement or note to the main Jupyter list might be warranted. Hence the following, brief history. I also promise to try to not be a drama queen.
Some of you may remember, from back when the Jupyter project was still known as the IPython notebook, a talented and prolific coder of the name Takafumi Arakaki, or tkf, who created an alternative client to the notebook server’s default web browser interface.
This client, which he called the Emacs IPython Notebook (you can still find his project on GitHub), or EIN, provided a complete IPython notebook experience in the venerable Emacs editor. Not only was EIN nearly feature complete when compared to the browser interface it also provided some useful features for the Python programmer, like allowing one to connect Python buffers to a notebook and using jedi for autocompletion in the notebook buffer.
Around March/April of 2014, just as IPython was advancing towards 1.0 and making big changes in the notebook/contents API and the kernel communication protocol, tkf mysteriously stopped pushing commits to his github repository.
I did not know tkf other than from a couple brief conversations. I sincerely hope tkf’s story has a happy end (he does appear to still push the occasional commit); he is clearly a talented programmer and without him this impressive piece of software would not exist.
This is the point where yours truly enters the story. I had discovered the IPython notebook the previous year and had found it an exteremly useful for analyzing the performance of catalytic process units in the refining industry and for working with Python in general, but being a long-time Emacs user I had somewhat bounced of the web interface. Discovering EIN was a godsend, and it quickly became a mainstay in my set of analytic tools.
Unfortunately the changes in going to v1.0 of the IPython notebook broke EIN, and with tkf apparently out of the picture there did not seem much hope in EIN staying compatible. Considering that I am a father of two with a full-time job that has absolutely nothing to do with programming (and yet I am a long-time Emacs user — it’s complicated, don’t ask), I can only describe what happened next as an act of complete insanity: I decided to fork tkf’s code, dig in and try to keep up with the changes in ipython.
Truthfully, no one was more surprised than I when I was actually able to keep ein working with versions 1.0 and, soon after, 2.0 of IPython. In fact that compatibility, in theory, is still in the code. One, again in theory, should be able to fire up a 1.x or 2.x version of the IPython notebook and connect to it using my fork of EIN. I say in theory, though, as I haven’t touched that part of the code in some time and it undoubtedly has suffered some bit rot in the intervening years.
The rest of the story is less interesting. Eventually I managed to convince GitHub and MELPA to treat my repository as the official version of ein. There was some short-lived talk of renaming my fork to ‘zwei’, but the consensus was that things were confusing enough with the change in ownership and to keep the name as ein.
Currently one can download ein through either MELPA or el-get, and someone has even been kind enough to create a spacemacs layer with convenient VIM keybindings for the heathens.
At the moment EIN supports the recent incarnations of Jupyter notebook, v4.3.1, token authentication, _xsrf cookies and all. By the time you read this I may even have pushed some commits that allow one to start and automatically log in to a jupyter notebook server all from Emacs without having to drop into the terminal.
In all, EIN continues to be a viable alternative to the web browser client. It is not 100% feature complete, though, as it notably does not support widgets and quite possibly never will.
I haven’t kept close track of who is using EIN, but as of this writing it has 341 stars on github and 28,175 downloads from MELPA. I know EIN is being used in at least a couple businesses and from what I have heard it tends to be more popular among those with a programming background — scientists and engineers tend to prefer the web client which is not surprising since Emacs is not so much a text editor as it is a Way of (Un)Life.
I encourage anyone who is interested in trying out ein to install it via MELPA or from the Spacemacs ipython-notebook layer. For slightly more information see the Quick Try and Usage sections in the documentation. The information there is not perfect but it is hopefully good enough to get you started with the tool. If you run into trouble do not hesitate to open an issue on GitHub; this is a hobby project but I get a lot of joy working with this code and will do my best to support it.
If you have made it this far then my sincere thanks for staying patient through my ramblings. As a parting thought I want to express my sincere thanks to Takafumi Arakaki, wherever he may be, and to the Jupyter team for their fantastic work in creating this amazing piece of software.
John Miller
