Improving Reproducibility of Interactive Notebooks Using Application Virtualization with FLINC2

FLINC2's design is general, based on interactive computation and client-server architecture, making it adaptable to various notebook platforms like JupyterHub and those supported by HydroShare. Experiments using notebooks from hydrology, data science, and earth science domains demonstrate FLINC2's effectiveness. It generates lighter containers than equivalent batch containers and maintains interactive workflows without platform modifications. The tool's source code and documentation are available via GitHub.

Interactive notebooks, such as Jupyter, are popular in scientific computing for their ability to facilitate interactive workflow development, data exploration, and visualization. However, despite being shareable, notebooks frequently suffer from reproducibility issues due to the lack of included computational environments and difficulties in resolving both explicit and implicit dependencies, leading to 'dependency hell' in different execution environments.

Application virtualization (AV) offers a lightweight solution to share code, data, and environment. Existing AV tools typically support non-interactive, batch applications, capturing dependencies during an 'audit' phase to enable 'repeat' execution. However, these tools are not suitable for the interactive, client-server architecture of notebooks, as they cannot handle dynamic modifications and communication protocols inherent in notebook interactions.

FLINC2 is introduced as an easy-to-use user-space tool that extends application virtualization to interactive notebooks. It virtualizes the notebook process, capturing the environment and all data dependencies without altering the notebook's content. FLINC2's design accommodates the interactive nature of notebooks and their client-server architecture, ensuring consistent behavior and 'flexible reproducibility' across diverse environments.

FLINC2 operates in two phases: 'audit' and 'repeat'. During the audit phase, it creates a lightweight notebook container with all necessary dependency files. In the repeat phase, it uses this container for seamless execution. A key feature is its ability to check for notebook modifications; if no changes are detected, it re-executes using the container. If changes are made, it resumes regular execution with the target environment. FLINC2 also includes an 'export' mechanism to transfer audited containers to non-notebook environments, ensuring broader reproducibility.

The paper uses a motivating scenario involving collaborative scientists (Alice, Bob, Charlie) to illustrate the reproducibility problems FLINC2 solves. For instance, Bob can use FLINC2 to run Alice's notebook in his own notebook environment, while Charlie can leverage the export feature to run it in a non-notebook environment, ensuring that the computational workflow produces consistent results despite environmental differences.