An Effective Personal Jupyter Data Science Workflow

I would like to share what I have found to be a very effective personal Jupyter workflow for data science development.

Jupyter (nee IPython) workbooks are JSON documents that allow a data scientist to mix: code, markdown, results, images, and graphs. They are a great contribution to scientific reproducibility, as they can contain a number of steps that can all be re-run in batch. They serve a similar role to literate programming, SWEAVE, and rmarkdown/knitr. The main design difference is Jupyter notebooks do not separate specification from presentation, which causes a number of friction points. They are not legible without a tool (such as JupyterLab, Jupyter Notebook, Visual Studio Code, PyCharm, or other IDEs), they are fairly incompatible with source control (as they may contain images as binary blobs, and many of the tools alter the notebook on opening), and they make greping/searching difficult.

The above issues are fortunately all inessential difficulties. Python is a very code-oriented work environment, so most tools expose a succinct programable interface. The tooling exposed by the Python packages IPython, nbformat, and nbconvert are very powerful and convenient. With only a little organizing code I was able to build a very powerful personal data science workflow that I have found works very well for clients.

I share this small amount of code in the package wvpy. This is easiest to demonstrate in action.

The first feature is: converting Jupyter notebooks (which are JSON files ending with a .ipynb suffix) to and from simple Python code that is more compatible with source control (such as Git).

Let’s start with a simple example Jupyter notebook: plot.ipynb. If we install (using a shell such as bask, or zsh) wvpy from PyPi.

pip install wvpy

And we download plot.ipynb

wget https://raw.githubusercontent.com/WinVector/wvpy/main/examples/worksheets/plot.ipynb

Then we can convert the Jupyter notebook to the Python formatted file as follows (we discuss this format a bit here).

python -m wvpy.pysheet --delete plot.ipynb

The tool reports the steps it takes in the conversion.

from "plot.ipynb" to "plot.py"
copying previous output target "plot.py" to "plot.py~"
converting Jupyter notebook "plot.ipynb" to Python "plot.py"
moving input plot.ipynb to plot.ipynb~

The resulting Python file is shown here. The idea is: the entire file is pure Python, with the non-python blocks in multi-line strings. This file has all results and meta-data stripped out, and a small amount of whitespace regularization. This “.py” format is exactly the right format for source control, we get reliable and legible differences. In my personal practice I don’t check “.ipynb” files in to source control, but only the matching “.py” files. This discipline makes greping and searching for items in the project as easy as finding items in code.

In the “.py” file “begin text”, “end text”, and “end code” markers show where the Jupyter cell boundaries are. This allows reliable conversion from the “.py” file back to a Jupyter notebook. PyCharm and others have a similar notebook representation strategy.

We can convert back from “.py” to “.ipynb” as follows.

python -m wvpy.pysheet --delete plot

from "plot.py" to "plot.ipynb"
converting Python plot.py to Jupyter notebook plot.ipynb
moving input plot.py to plot.py~

Notice this time we did not specify the file suffix (the “.py” or “.ipynb”). The tooling checks that exactly one of these exists and converts one to another. This allows easy conversion back and forth reusing command history.

Either form of the worksheet can be executed and rendered by HTML from the command line as follows.

python -m wvpy.render_workbook plot

start render_as_html "plot.ipynb" 2022-08-20 12:19:06.669369
done render_as_html "plot.html" 2022-08-20 12:19:10.080226

This produces what we expect to see from a Jupyter notebook as a presentation.

There is also an option in the HTML renderer that strips out input blocks. This isn’t fully presentation ready, but it makes for very good in progress work reports.

python -m wvpy.render_workbook --strip_input plot

start render_as_html "plot.ipynb" 2022-08-20 12:19:35.251560
done render_as_html "plot.html" 2022-08-20 12:19:38.478107

This gives a simplified output as below.

We also supply a simple class for holding render tasks, including inserting arbitrary initialization code for each run. This makes it very easy to render the same Jupyter workbook for different targets (say the same analysis for each city in a state) and even parallelize the rendering using standard Python tools such as multiprocessing.Pool. This parameterized running allows simple management of fairly large projects. If I need to run a great many variations of a notebook I use the JTask container and either a for loop or multiprocessing.Pool over the tasks in Python (remember, when we have Python we don’t have to perform all steps at the GUI or even in a shell!).

I have found the quickest development workflow is to work with the “.ipynb” Jupyter notebooks (usually in Visual Studio Code, and settng any values that were supposed to come from the wvpy.render_workbook by hand after checking they are not set in globals()). Then when the worksheet is working I convert it to “.py” using wvpy.pysheet and check that in to source control.

As a side-note I find Python is a developer first community, which is very refreshing. Capabilities (such as Jupyter, nbconvert, and nbformat) are released as code under generous open source licenses and documentation instead of being trapped in monolithic applications. This means one can take advantage of their capabilities using only a small amount of code. And under the mentioned assumption that Python is a developer first community, small amounts of code are considered easy integrations. wvpy is offered in the same spirit, it is available for use from PyPi here under a BSD 3-clause License and has it code available here for re-use or adaption here under the same license. It isn’t a big project, but it has made working on client projects and teaching data science a bit easier for me.

In conclusion, that is my current personal Jupyter workflow. It improves compatibility with source control, ease of search, and automatic rendering of many worksheets in a parameterized manner. I feel this addresses the primary pain points of working with Jupyter worksheets.

I’ll be offering private (and hopefully someday public) training on the work flow (including notebook parameterization to run many jobs from a single source, use of multiprocessing.Pool for speedup, and IPython.display.display; IPython.display.Markdown for custom results) going forward.