Packaging Jupyter notebooks as installable desktop apps using LabConstrictor Iván Hidalgo-Cenalmor1,2, Marcela Xiomara Rivera Pineda1,2,3, Bruno M. Saraiva4, Ricardo Henriques4,5, and Guillaume Jacquemet1,2,3,6,1Turku Bioscience Centre, University of Turku and Åbo Akademi University, Turku, FI 2Faculty of Science and Engineering, Cell Biology, Åbo Akademi University, Turku, FI 3InFLAMES Research Flagship Centre, University of Turku, Turku, FI 4Instituto de Tecnologia Química e Biológica António Xavier, Universidade Nova de Lisboa, Oeiras, Portugal 5UCL Laboratory for Molecular Cell Biology, University College London, London, United Kingdom 6Foundation for the Finnish Cancer Institute, Tukholmankatu 8, Helsinki, FI Life sciences research depends heavily on open-source academic software, yet many tools remain underused due to practical barri- ers. These include installation requirements that hinder adoption and limited developer resources for software distribution and long-term maintenance. Jupyter notebooks are popular because they combine code, documentation, and results into a single executable document, enabling quick method development. How- ever, notebooks are often fragile due to reproducibility issues in coding environments, and sharing them, especially for local execution, does not ensure others can run them successfully. Lab- Constrictor closes this deployment gap by bringing CI/CD-style automation to academic developers without needing DevOps expertise. Its GitHub-based pipeline checks environments and packages notebooks into one-click installable desktop applica- tions. After installation, users access a unified start page with documentation, links to the packaged notebooks, and version checks. Code cells can be hidden by default, and run-cell controls combined with widgets provide an app-like experience. By sim- plifying the distribution, installation, and sharing of open-source software, LabConstrictor allows faster access to new computa- tional methods and promotes routine reuse across labs. Jupyter Notebook | Reproducibility | Software Packaging | User-Friendly Correspondence: (G. Jacquemet) Introduction Open-source academic software has become essential to life sciences research. It facilitates the collection, storage, anal- ysis, visualisation, and sharing of data. Microscopy is a key example: modern imaging routinely produces large, complex datasets, including 3D volumes, multiplexed acquisitions, and time-lapse movies. The amount of information that can be extracted from these data continues to grow as image anal- ysis methods advance. Extracting quantitative biological in- sights from data involves navigating a broad, rapidly evolving software ecosystem, ranging from well-known graphical ap- plications such as Fiji (Schindelin et al., 2012) or QuPath (Bankhead et al., 2017) to research code available as Python toolboxes (Weigert et al., 2018; Stringer et al., 2021; Schmidt et al., 2018). State-of-the-art image analysis algorithms, especially AI- driven methods, are often implemented in Python because it allows quick iteration and easy reuse of community libraries. However, Python-based tools can be hard for non-experts to use in practice because they often require installing and managing complex dependencies across different operating systems. At the same time, many academic developers lack the resources to package, distribute, and maintain user-friendly software, which widens the gap between rapid method de- velopment and everyday real-world application. Therefore, the impact of software depends not only on creating better algorithms but also on making sure others can easily install it and that it continues to work over time. Notebook (.ipynb) requirements.yaml def run(): External code (.py) Developer Provides: Generate OS Installers User Installs an App Template + automatic workflows Labconstrictor Provides: JupyterLab Notebook 1 # Hidden code Output of code Widget 1 Widget 2 Dropdown Hide/Show Code User Interacts with Friendly Notebooks 1 3 4 2 Fig. 1. LabConstrictor overview. High-level schema showing how developer inputs (Jupyter notebooks, optional external Python code, and dependency specifications) populate a GitHub template repository to produce OS-specific installers, a desktop application, and a guided notebook experience in JupyterLab. Jupyter notebooks offer a practical balance between rapid de- velopment and dissemination. By combining code, narrative explanations, and outputs within a single executable docu- ment, notebooks facilitate the presentation of the full analysis workflow and support more guided interaction (Perkel, 2018). Tools such as ipywidgets, EZInput (Saraiva et al., 2026), and marimo enable developers to expose parameters and controls, thereby minimising the need for users to modify code directly. Consequently, notebooks have become a common format for sharing computational approaches in data science and increas- ingly in the life sciences. However, “sharing a notebook” does not necessarily mean it is reusable: a notebook that functions for its author might not work elsewhere due to differences in operating systems, Python versions, or library dependencies (Rule et al., 2019; Pimentel et al., 2019; Samuel and Mietchen, 2024). Cloud platforms such as Binder (Jupyter et al., 2018) and rxiv-maker | Hidalgo-Cenalmor et al. | March 12, 2026 | 1–6 arXiv:2603.10704v1 [cs.SE] 11 Mar 2026 Google Colab lower initial barriers by providing ready-to-use environments in the browser. Tools built on Google Colab, including ZeroCostDL4Mic (von Chamier et al., 2021), Cell- TracksColab (Gómez-de Mariscal et al., 2024), and ColabFold (Mirdita et al., 2022), have supported many research projects. However, cloud execution is not always feasible when clini- cal data and other sensitive microscopy datasets cannot leave institutional firewalls due to privacy, governance, or compli- ance requirements. In addition, many imaging datasets are simply too large and complex to upload to cloud resources (e.g., 3D volumes or entire pathology slides). In these cases, researchers still require reliable methods for running notebook- based workflows reproducibly on local or institutional infras- tructure. Several efforts aim to enhance the local reproducibil- ity and accessibility of notebook workflows, includ- ing DL4MicEverywhere (Hidalgo-Cenalmor et al., 2024), JupyterLab Desktop, and album (Albrecht et al., 2021). DL4MicEverywhere packages notebooks using Docker to improve stability and portability, but Docker can introduce setup and operational complexity (e.g., resource management and GPU configuration) and is sometimes constrained by insti- tutional IT and security policies. JupyterLab Desktop makes it easy to launch notebooks, but users still need to manage Python environments. Album supports cross-platform sharing of scientific software, yet preparing tools for distribution can still require significant developer time and familiarity with packaging conventions. Here, we present LabConstrictor, a framework that reduces practical barriers by packaging and distributing Jupyter note- books as installable desktop applications (Fig. 1). For develop- ers, LabConstrictor offers a well-documented, zero-command- line workflow built around Continuous Integration (CI) and Continuous Deployment (CD) automation for validation, pack- aging, and releases (Fig. 2A). For end users, it delivers an installation and launch experience that feels more like using a standalone application than managing a Python environment (Fig. 2B). Making notebooks easy to package and install LabConstrictor is designed for notebook authors who want to distribute a functional workflow without converting it into a full software project with a dedicated graphical interface. It is shared as a GitHub template repository with a predefined structure, starter documentation, and automated GitHub Ac- tions that manage most validation and packaging steps (see Automation in Fig. 2A). Developers mainly interact with the setup and packaging processes via the GitHub web interface and a web-based configuration form. These interfaces are used to set repository-specific options (including basic branding), manage notebooks and their dependencies, and create releases with the corresponding executables (see Developer pipeline in Fig. 2A). Converting a notebook into an installable app requires min- imal direct code editing and follows simple, guided steps. Additionally, to support dependency specification, which is often one of the most time-consuming parts, LabConstric- tor provides a helper notebook that assesses the environment where the notebook runs (locally or online) to generate an ini- tial requirements file, which can then be refined and validated. LabConstrictor also offers documentation and suggestions to adapt notebooks originally built for Google Colab (e.g., handling paths and environment-specific user interfaces) so they can run smoothly in a local environment. Finally, Lab- Constrictor enables developers to include external Python code alongside notebooks to share functionality across multi- ple workflows. A minimal demonstration repository derived from the LabConstrictor template is also provided at https: //github.com/CellMigrationLab/LabConstrictor_Demo to il- lustrate the expected repository structure and workflow setup. Because LabConstrictor is distributed as a template repository, each packaged workflow resides in its own GitHub repository, allowing developers full control over documentation, visibility, and access permissions. This is especially important for core facilities and institutional deployments where workflows may need to stay private while still benefiting from LabConstric- tor’s automated validation, packaging, and local execution. LabConstrictor allows offline use after installation, which is essential for secure environments, institutional firewalls, and low-connectivity settings. For notebooks that do not depend on remote resources (such as repository cloning or dataset downloads), the packaged workflow operates completely lo- cally. Automated validation and version awareness As notebook workflows evolve, changes in dependencies can introduce incompatibilities that compromise functionality. LabConstrictor mitigates this risk by providing default GitHub Actions continuous integration (CI) workflows that validate the packaged environment (by creating a fresh conda environ- ment and installing the specified dependencies) and prevent the release of non-functional deployments (see Automation in Fig. 2A). Once a stable environment is reached, a release- triggered CI workflow builds installers for Windows (.exe), macOS (.pkg), and Linux (.sh) using conda’s constructor, en- abling a zero command-line interaction for both developers and end users. The installers provide a user-friendly graphical interface and automatically set up the validated environment, creating a desktop application via conda’s menuinst. This simplifies the process for end users, who can install the workflow like a typical desktop application rather than building Python envi- ronments or resolving package conflicts. To support consistent maintenance as notebooks evolve, Lab- Constrictor offers lightweight helper components that track versioning and notify users of available updates. Where sup- ported, these components can also update notebooks without requiring users to reinstall the entire application. When fail- ures occur during automated workflows, LabConstrictor gen- erates logs intended to help with troubleshooting. These logs are designed to serve as input to large language models to facil- itate faster diagnosis of common errors and, when necessary, 2 Hidalgo-Cenalmor et al. | LabConstrictor B End user experience Next > Cancel Welcome to CustomApp 0.0.1 Setup! Next > Cancel Welcome to CustomApp 0.0.1 Setup! .exe .pkg .sh JupyterLab Notebook 1 Welcome notebook Notebook 2 Open Update Open Updated JupyterLab Notebook 1 # Hidden code Output of code Widget 1 Widget 2 Dropdown Hide/Show Code .exe .pkg .sh JupyterLab Notebook 1 Welcome notebook Notebook 2 Open Update Open Updated JupyterLab Notebook 1 # Hidden code Output of code Widget 1 Widget 2 Dropdown Hide/Show Code Automation B Create welcome notebook Modify code for the App Build an App installer per OS (conda constructor + menuinst) Windows MacOS Linux Upload Assets A In case of failure: Revert breaking contribution Create a log file ready for LLMs Track versions/changelog Hide code in notebooks Merge notebook requirements Validate conda environment built with merged requirements Assets Custom Repository Activate automation B v0.0.1 New Release 5 Create Release Upload notebook Upload dependencies 01_Analysis.ipynb requirements.yaml Custom Repository Create Pull Request Activate automation A Submit Files 4 requirements.yaml python: 3.9 dependencies: - pandas==3.0.0 Dependencies File 01_Analysis.ipynb helper.py Requirements_Generator.ipynb Scans for imports to build dependencies file Upload notebooks and external code Generate Requirements 3 Use this template LabConstrictor Custom Repository Project Name... Version... Upload Icon Initialise repository Choose Repository Upload Changes Custom Repository Pull Request icon.png Initialise your Repository from Template 2 01_Analysis.ipynb helpers.py import pandas as pd icon.png 1 Prepare your Notebooks and Optional External Code and Icon Developer pipeline A Developer Workflow Changes on code Automation B Create welcome notebook Modify code for the App Build an App installer per OS (conda constructor + menuinst) Windows MacOS Linux Upload Assets A In case of failure: Revert breaking contribution Create a log file ready for LLMs Track versions/changelog Hide code in notebooks Merge notebook requirements Validate conda environment built with merged requirements Assets Custom Repository Activate automation B v0.0.1 New Release 5 Create Release Upload notebook Upload dependencies 01_Analysis.ipynb requirements.yaml Custom Repository Create Pull Request Activate automation A Submit Files 4 requirements.yaml python: 3.9 dependencies: - pandas==3.0.0 Dependencies File 01_Analysis.ipynb helper.py Requirements_Generator.ipynb Scans for imports to build dependencies file Upload notebooks and external code Generate Requirements 3 Use this template LabConstrictor Custom Repository Project Name... Version... Upload Icon Initialise repository Choose Repository Upload Changes Custom Repository Pull Request icon.png 2 01_Analysis.ipynb helpers.py import pandas as pd icon.png 1 Developer pipeline Changes on code Fig. 2. LabConstrictor workflow for developers and end-users. (A) Authors prepare notebooks (and optional assets), initialize a custom repository from the LabConstrictor template, generate or curate requirements, and submit notebooks and dependencies through web forms (steps 1–5). GitHub Actions automate validation, notebook formatting, and environment setup (step A), and handle release packaging and generate installers for Windows, macOS, and Linux (step B). (B) End users install the desktop app via a standard installer, launch a local JupyterLab session with a welcome notebook for navigation, and run notebooks with reduced code exposure and simple execution controls. Hidalgo-Cenalmor et al. | LabConstrictor 3 improve communication between users and developers. From installer to analysis: the user workflow For end users, LabConstrictor simplifies setup and makes it easy to find and use installed notebooks. There is no need to create Python environments, install additional packages, or resolve dependency conflicts. LabConstrictor also provides guidance through the installation process and on using note- books in local JupyterLab sessions, making the experience more user-friendly (Fig. 2B). End users can start by installing the app on their computers, and since it runs locally, they can access their own data and re- sources directly. After downloading and running the installer, users see a desktop application. When they open the app, a local JupyterLab session launches in the default browser, displaying a welcome notebook to help users get started. The goal is to make the workflow feel like using an app, rather than just running code. The welcome notebook not only guides users but also per- forms version checks to ensure they are using the correct environment. It provides a clear starting point for exploring available notebooks. Within each notebook, code can be hid- den, and users can reveal cells with simple controls, similar to Google Colab but running locally. A key benefit of LabConstrictor is its ability to run offline. For workflows that don’t need remote resources (such as cloning repositories or downloading datasets), the packaged applica- tion can operate completely offline after installation. This is especially important for sensitive data and clinical research within restricted institutional environments. Conclusions As AI-driven analysis in the life sciences increasingly de- pends on quickly evolving Python workflows, reproducible local deployment becomes essential, especially when data cannot leave institutional infrastructure. LabConstrictor sup- ports this by making setup easier and enabling reliable local use of Jupyter-based workflows. It packages notebooks into installable desktop applications that run in a validated envi- ronment, reducing barriers for both developers and end users. In many labs, the main challenge is not creating a notebook but ensuring it works across different computers. By closing this deployment gap, LabConstrictor helps turn quickly shared notebook methods into tools regularly used in practice. Methods Repository initialisation and customisation. LabConstric- tor is distributed as a GitHub template repository containing a predefined folder structure, internal documentation, and automated workflows. When a developer instantiates the template, the resulting repository initially contains default placeholders. To support rapid customisation and provide a consistent end-user experience, we developed a web-based configuration form implemented as a Streamlit application (https://labconstrictor-form.streamlit.app/). The form collects basic project metadata (project name and initial version) and, optionally, images (e.g., logo, header, and welcome image) for branding. After submission, the developer provides the GitHub repos- itory URL and a GitHub Personal Access Token (PAT) to authorise access to the repository. The configuration form then replaces placeholders within the template repository and opens a pull request containing the customised content, allow- ing the developer to review and merge the changes. Dependency specification and requirements generation. Ac- curately specifying dependencies for notebook workflows can be challenging, particularly when version pinning is required for reproducibility. LabConstrictor includes a requirements generation notebook to guide developers through this process. This notebook needs to be executed in the same environment where the target workflow already runs (e.g., a local conda environment/virtualenv, or a Google Colab session), so the tool can access installed packages and their versions directly. The requirements generation notebook requests the path to the target notebook and scans code cells for import statements to infer required packages. It also detects installation commands (e.g., pip install) and prompts the developer to confirm that these packages are installed in the active environment so they can be versioned correctly. If external Python code is used (see ‘External code support’ section), the notebook can addi- tionally scan specified .py files to capture imports outside the notebook. Detected packages are then validated against the current environment, and version information is recorded. The output is a requirements.yaml file that includes (i) a short notebook description for display purposes, (ii) the Python ver- sion, and (iii) a versioned list of dependencies. In addition, for developers who prefer to write requirements.yaml manually, we provide a validation notebook to check the file format. Uploading notebooks and triggering automated validation. Once notebooks and their requirements have been validated, they are uploaded to the repository using the web form (https://labconstrictor-form.streamlit.app/). This form sup- ports uploading multiple notebooks and their corresponding requirements files, and creates a pull request that inserts files into the correct repository structure. When the pull request is merged, an automated GitHub Actions workflow is triggered to validate the contribution. This automation handles (i) version tracking and changelog updates, (ii) formatting steps for notebooks (including code hiding, see ‘Notebook code hiding and app-like interaction’), (iii) merging requirements from submitted notebooks, and (iv) environment validation. When merging requirements, the workflow first ensures that all notebooks specify compatible Python versions; if they differ, it fails early. If Python versions are consistent, dependencies are combined into a single speci- fication, and in case of conflicting version pins, the workflow chooses the latest version. Environment validation runs on Ubuntu to optimize time and computational resources. A new conda environment is created 4 Hidalgo-Cenalmor et al. | LabConstrictor using the combined Python version, and dependencies are in- stalled from PyPI. If environment setup or package installation fails, the GitHub Actions workflow fails and automatically reverts the commit related to the notebook submission, en- suring that non-functional notebooks are not included in the installable distribution. Additionally, a troubleshooting log is generated that includes the relevant requirements, scripts, and error output, enabling developers to diagnose issues indepen- dently or with the help of a large language model (LLM), and communicate problems efficiently. External code support. LabConstrictor supports workflows that depend on Python code outside the notebook (e.g., shared helper functions reused across multiple notebooks). Develop- ers can upload external Python modules to the repository, and automated GitHub workflows will include these files in the distributable application. During installation, a setup.py pro- vided by LabConstrictor installs the external code as a Python package inside the created environment, enabling standard imports from notebooks. Version tracking and update awareness. To simplify ver- sion tracking, developers only need to define a variable (cur- rent_version = "0.0.1") in any notebook cell. A GitHub Ac- tions script scans notebook code cells, retrieves the specified version, and stores it in a YAML file to ensure reliable check- ing. Version information is provided to end users through the wel- come notebook launched by the desktop application. The welcome notebook compares the locally installed notebook version to the latest available in the repository and notifies the user if an update is ready. When supported, the interface of- fers an update option to download the latest notebook version without needing a full application reinstall. Additionally, the desktop application itself is versioned via repository releases, enabling update notifications when necessary. Notebook code hiding and app-like interaction. To prevent an overwhelming interface for end users, LabConstrictor de- faults to hiding code cells. While standard notebook collaps- ing can be accidentally undone when a user clicks into a cell, LabConstrictor uses a dedicated JupyterLab plugin (jl-hide- code, distributed via PyPI) that adds a toolbar button to toggle code visibility. When code is hidden, it stays hidden until the user explicitly makes it visible again. To enhance app-like interaction, hidden cells can show a play- style execution button near the cell, similar to Google Co- lab. Code hiding can also be implemented programmatically through cell tags. In LabConstrictor, these tags are added au- tomatically during notebook submission via GitHub Actions, so notebooks come with code hidden by default. Developers can turn off this behavior during repository initialization if end users are expected to edit code directly. Building executable installers and desktop applications. LabConstrictor generates installable executables using the conda constructor tool, which creates platform-specific in- stallers that set up a conda environment with predefined pack- ages. The installer bundles additional files needed for dis- tribution, including notebooks, optional external code, the welcome notebook, and application resources. Then, a post- install script installs the specified Python dependencies and other components required for the notebook experience (e.g., JupyterLab, ipywidgets, and the jl-hide-code plugin) into the conda environment via PyPI. While conda with pinned dependency versions can ensure strong reproducibility, this approach is not always flawless across different operating systems and can still be impacted by the long-term availability of upstream packages (for ex- ample, if a PyPI release is removed or becomes inaccessible). Complementary strategies based on containerization, such as DL4MicEverywhere (Hidalgo-Cenalmor et al., 2024), can ad- dress these issues by fully encapsulating the runtime environ- ment, thus enhancing cross-system consistency and long-term reproducibility, although they require a more complex setup. To provide a desktop entry point, LabConstrictor uses men- uinst to create a desktop application that launches a Jupyter- Lab session within the installed environment and automati- cally opens the welcome notebook. Together, these steps provide a guided installation process via a graphical installer and a local desktop application that launches a controlled JupyterLab environment for navigating and running the packaged notebooks. ABOUT THIS MANUSCRIPT This work is licensed under CC BY 4.0. CODE AVAILABILITY LabConstrictor is available at https://github.com/CellMigrationLab/LabConstrictor under an MIT License. A minimal example repository showing how to build a LabConstrictor-based workflow is available at https://github.com/CellMigrationLab/ LabConstrictor_Demo. AUTHOR CONTRIBUTIONS G.J.and I.H.-C. conceived the study in its initial form; I.H.-C. developed the LabCon- strictor framework with input from G.J.; G.J. and M.R. provided critical feedback, testing, and guidance; G.J. acquired funding; G.J.and I.H.-C. wrote the manuscript with input from all authors. ACKNOWLEDGEMENTS I.H.C. is funded by the Finnish Doctoral Program Network in Artificial Intelligence, AI-DOC (decision number VN/3137/2024-OKM-6). This study received funding from the Research Council of Finland (338537, 371287, and 374180 to G.J.), the Sigrid Juselius Foundation (to G.J.), the Cancer Society of Finland (Syöpäjärjestöt; to G.J.), and the Solutions for Health strategic funding for Åbo Akademi University (to G.J.). Additionally, this research was supported by the InFLAMES Flagships Programme of the Research Council of Finland (decision numbers: 337530, 337531, 357910, and 35791). G.J. is supported by the Finnish Cancer Institute (K. Albin Johansson Professorship). This project has received funding from the European Research Council (ERC) under the European Union’s Horizon 2020 research and innovation programme (grant agreement No. 101001332 to R.H.). This project also received funding from the European Union through the Horizon Europe EIC Pathfinder Open program (RT-SuperES, grant agreement No. 101099654 to R.H.). Funded by the European Union. However, the views and opinions expressed are those of the authors only. They do not necessarily reflect those of the European Union or the granting authority. Neither the European Union nor the granting authority can be held responsible for them. This work was supported by a European Molecular Biology Or- ganization (EMBO) installation grant (EMBO-2020-IG-4734 to R.H.). Further support was provided by a Chan Zuckerberg Initiative Essential Open Source Software for Science grant (EOSS6-0000000260 to R.H. and G.J.). The project has also received funding from the "la Caixa" Foundation under the project code HR25-00453 (to R.H.). COMPETING FINANCIAL INTERESTS The authors declare that they have no competing or financial interests. EXTENDED AUTHOR INFORMATION Hidalgo-Cenalmor et al. | LabConstrictor 5 Bibliography Johannes Schindelin, Ignacio Arganda-Carreras, Erwin Frise, Verena Kaynig, Mark Longair, Tobias Pietzsch, Stephan Preibisch, Curtis Rueden, Stephan Saalfeld, Benjamin Schmid, Jean-Yves Tinevez, Daniel James White, Volker Hartenstein, Kevin Eliceiri, Pavel Tomancak, and Albert Cardona. Fiji: an open-source platform for biological-image analysis. Nature Methods, 9(7): 676–682, 2012. doi:10.1038/nmeth.2019. Peter Bankhead, Maurice B. Loughrey, José A. Fernández, Yvonne Dombrowski, Darragh G. McArt, Philip D. Dunne, Stephen McQuaid, Ronan T. Gray, Liam J. Murray, Helen G. Coleman, Jacque- line A. James, Manuel Salto-Tellez, and Peter W. Hamilton. Qupath: Open source software for digital pathology image analysis. Scientific Reports, 7(1), 2017. doi:10.1038/s41598-017- 17204-5. Martin Weigert, Uwe Schmidt, Tobias Boothe, Andreas Müller, Alexandr Dibrov, Akanksha Jain, Benjamin Wilhelm, Deborah Schmidt, Coleman Broaddus, Siân Culley, Mauricio Rocha-Martins, Fabián Segovia-Miranda, Caren Norden, Ricardo Henriques, Marino Zerial, Michele Solimena, Jochen Rink, Pavel Tomancak, Loic Royer, Florian Jug, and Eugene W. Myers. Content-aware image restoration: pushing the limits of fluorescence microscopy. Nature Methods, 15(12): 1090–1097, 2018. doi:10.1038/s41592-018-0216-7. Carsen Stringer, Tim Wang, Michalis Michaelos, and Marius Pachitariu. Cellpose: a generalist al- gorithm for cellular segmentation. Nature Methods, 18(1):100–106, 2021. doi:10.1038/s41592- 020-01018-x. Uwe Schmidt, Martin Weigert, Coleman Broaddus, and Gene Myers. Cell Detection with Star- Convex Polygons, pages 265–273. Springer International Publishing, 2018. doi:10.1007/978- 3-030-00934-2_30. Jeffrey M. Perkel. Why jupyter is data scientists’ computational notebook of choice. Nature, 563 (7729):145–146, 2018. doi:10.1038/d41586-018-07196-1. Bruno M. Saraiva, Iván Hidalgo-Cenalmor, António D. Brito, Damián Martínez, Tayla Shakespeare, Guillaume Jacquemet, and Ricardo Henriques. Ezinput: A cross-environment python library for easy ui generation in scientific computing, 2026. doi:10.48550/ARXIV.2601.08859. Adam Rule, Amanda Birmingham, Cristal Zuniga, Ilkay Altintas, Shih-Cheng Huang, Rob Knight, Niema Moshiri, Mai H. Nguyen, Sara Brin Rosenthal, Fernando Pérez, and Peter W. Rose. Ten simple rules for writing and sharing computational analyses in jupyter notebooks. PLOS Computational Biology, 15(7):e1007007, 2019. doi:10.1371/journal.pcbi.1007007. Joao Felipe Pimentel, Leonardo Murta, Vanessa Braganholo, and Juliana Freire. A large- scale study about quality and reproducibility of jupyter notebooks. 2019 IEEE/ACM 16th International Conference on Mining Software Repositories (MSR), pages 507–517, 2019. doi:10.1109/MSR.2019.00077. Sheeba Samuel and Daniel Mietchen. Computational reproducibility of jupyter notebooks from biomedical publications. GigaScience, 13, 2024. doi:10.1093/gigascience/giad113. Project Jupyter, Matthias Bussonnier, Jessica Forde, Jeremy Freeman, Brian Granger, Tim Head, Chris Holdgraf, Kyle Kelley, Gladys Nalvarte, Andrew Osheroff, M Pacer, Yuvi Panda, Fernando Perez, Benjamin Ragan-Kelley, and Carol Willing. Binder 2.0 - reproducible, interactive, sharable environments for science at scale. Proceedings of the Python in Science Conference, pages 113–120, 2018. doi:10.25080/Majora-4af1f417-011. Lucas von Chamier, Romain F. Laine, Johanna Jukkala, Christoph Spahn, Daniel Krentzel, Elias Nehme, Martina Lerche, Sara Hernández-Pérez, Pieta K. Mattila, Eleni Karinou, Séamus Holden, Ahmet Can Solak, Alexander Krull, Tim-Oliver Buchholz, Martin L. Jones, Loïc A. Royer, Christophe Leterrier, Yoav Shechtman, Florian Jug, Mike Heilemann, Guillaume Jacquemet, and Ricardo Henriques. Democratising deep learning for microscopy with zerocostdl4mic. Nature Communications, 12(1), 2021. doi:10.1038/s41467-021-22518-0. Estibaliz Gómez-de Mariscal, Hanna Grobe, Joanna W. Pylvänäinen, Laura Xénard, Ricardo Henriques, Jean-Yves Tinevez, and Guillaume Jacquemet. Celltrackscolab is a platform that enables compilation, analysis, and exploration of cell tracking data. PLOS Biology, 22(8): e3002740, 2024. doi:10.1371/journal.pbio.3002740. Milot Mirdita, Konstantin Schütze, Yoshitaka Moriwaki, Lim Heo, Sergey Ovchinnikov, and Martin Steinegger. Colabfold: making protein folding accessible to all. Nature Methods, 19(6): 679–682, 2022. doi:10.1038/s41592-022-01488-1. Iván Hidalgo-Cenalmor, Joanna W. Pylvänäinen, Mariana G. Ferreira, Craig T. Russell, Alon Saguy, Ignacio Arganda-Carreras, Yoav Shechtman, Arrate Muñoz-Barrutia, Beatriz Serrano-Solano, Caterina Fuster Barcelo, Constantin Pape, Emma Lundberg, Florian Jug, Joran Deschamps, Mariana G. Ferreira, Matthew Hartley, Mehdi Seifi, Teresa Zulueta-Coarasa, Vera Galinova, Wei Ouyang, Guillaume Jacquemet, Ricardo Henriques, and Estibaliz Gómez-de Mariscal. Dl4miceverywhere: deep learning for microscopy made flexible, shareable and reproducible. Nature Methods, 21(6):925–927, 2024. doi:10.1038/s41592-024-02295-6. Jan Philipp Albrecht, Deborah Schmidt, and Kyle Harrington. Album: a framework for scientific data processing with software solutions of heterogeneous tools, 2021. doi:10.48550/ARXIV.2110.00601. 6 Hidalgo-Cenalmor et al. | LabConstrictor