Quickfix: jupyter nbconvert with clear-output flag not working

Jupyter comes with a command line utility jupyter nbconvert that can transform a jupyter notebook into different formats. Furthermore, it has options to tweak the output. For instance, the execute flag executes the notebook before transforming it while the clear-output flag is supposed to remove outputs from the notebook. Thus, if you want to execute the notebook notebook.ipynb and transform it into a pdf file afterwards, you can issue the command

jupyter nbconvert notebook.ipynb --execute --to pdf

I stumbled upon the following problem when I tried to create a make target for the SCP project. The make target should do the following: It should clear the output of a specified notebook, execute it and then export it as a pdf file.

Problem description

In contrast to its purpose, the clear-output flag does not remove the output from any notebook. Suppose your Jupyter notebook is notebook.ipynb. Then,

jupyter nbconvert --clear-output notebook.ipynb

merely saves the file notebook.ipynb again. The output remains in the notebook.


Unfortunately, this still seems to be an open issue. However, there is a more specific version of the command available that does exactly what we want:

jupyter nbconvert --ClearOutputPreprocessor.enabled=True --inplace notebook.ipynb

It is not clear to me what the current status of the issue is; in fact, there are recent commits in other projects referencing the issue and the issue itself is labeled as upstream. Apparently, a dependency (traitlets) is causing this bug.

Quickfix: ‘Push rejected’ when deploying a Python app on Heroku

Heroku is a platform that enables you to deploy your web application in a quick and painless manner; unless you’re stumbling upon a ‘Push rejected’ error with next to no hint how to resolve it.

Problem description

I stumbled upon this when trying to deploy a flask app but I’m pretty sure this will also happen with django apps. Here’s what happened: When deploying to Heroku you first have to initialize a git repository. For Python apps in particular, you also have to provide a requirements.txt that consists of the dependencies of your application. This is pretty standard. What was new to me is that you also have to provide a runtime.txt that tells Heroku which Python version your app was written in. As naive as I was, I merely checked for the Python version in my Anaconda environment and put python-3.7.4 in the file, committed and pushed to Heroku via git push heroku master. Here’s what I got back:

remote: Compressing source files... done.
remote: Building source:
remote: -----> Python app detected
remote:  !     Python has released a security update! Please consider upgrading to python-3.7.3
remote:        Learn More: https://devcenter.heroku.com/articles/python-runtimes
remote: -----> Installing python-3.7.4
remote: -----> Installing pip
remote: -----> Installing requirements with pip
remote:  !     Push rejected, failed to compile Python app.
remote:  !     Push failed
An example of a non-helpful build log on heroku.com
An example of a non-helpful build log on heroku.com

That was not helpful at all. Especially the hint at upgrading to python-3.7.3 was confusing me because my proposed runtime was even more recent! The build log did not reveal anything new either.


After being confused for about half an hour, suspecting that Heroku could not cope with my requirements at first, I finally found out that Heroku does not support python-3.7.4 as a runtime! In fact, Heroku only supports three specific python runtimes at the moment. Thus, the solution is to simply use python-3.7.3 as a runtime.

Quickfix: Muting search highlights in Emacs Evil mode

This quickfix is about muting search highlights when using the text editor Emacs with its vim emulation Evil mode.

Problem description

A screenshot of Emacs showing a few highlighted search results.
Search highlighting in Emacs’ Evil mode.

Sometimes the quickest way to navigate through a file with vim is to enter a search term and work your way through the search results if necessary. Search highlighting may assist you by providing a visual clue as to what your current found result is and where the next results are. However, as soon as the cursor is in your desired position, search highlighting persists and can become a nuisance. Fortunately, there is a quick way to mute it on demand: The :noh command (short for :nohlsearch) has exactly this purpose. If you want an even more comfortable solution, you can create a custom shortcut in vim. Drew Neil suggests in Tip 80 of his book Practical Vim to bind the :noh command as an add-on to the key combination Ctrl+l:

  nnoremap <silent> <C-l> :<C-u>nohlsearch<CR><C-l>

This makes sense because Ctrl+l normally redraws the buffer in vim and muting of search highlights is a sensible feature to add. In Emacs, we may do the same and bind Ctrl+l to a macro executing the strokes :noh in evil normal state. However, there is a slightly faster solution available.


The variable evil-ex-commands, as its name suggests, contains the information which ex command corresponds to which lisp function. A quick call to describe variable (shortcut Ctrl+h Ctrl+v) and a search for “nohl” yield that :noh call the lisp function evil-ex-nohighlight. Thus,

;;; Shortcut for muting search highlighting
(define-key evil-normal-state-map (kbd "C-l") 'evil-ex-nohighlight)

is the desired solution. Note that the standard behavior of Ctrl+l in Emacs is to recenter the viewpoint at bottom, top or original center, a functionality which I personally do not need since Evil mode provides some alternatives (for example, H, M, and L jump to the top, center, and bottom, respectively, of the current buffer and zz centers the current cursor position vertically). However, if you also want to redraw the buffer just like in the vim solution the elisp function redraw-frame seems to do the trick.

;;; Shortcut for redrawing the current frame/buffer and muting search highlighting
(define-key evil-normal-state-map (kbd "C-l") (progn 'redraw-frame 'evil-ex-nohighlight))