Using Zepl Images to Manage Notebook Dependencies
September 13, 2021
One of the biggest shortcomings of open source notebooks is the lack of sharing and collaborating capabilities. It is common practice to put several install commands at the beginning of a notebook or script to help ensure that others will be able to recreate your analysis. Unfortunately, these libraries are not shared when the notebook is shared, so the person with whom you shared your notebook is often not able to run it.
Zepl eliminates all of that hassle. Every time you run a notebook in Zepl, you spin up a container which contains an “image” — a prebuilt environment with all the libraries and settings your team needs for reproducible data science. Images let you create Images that contain as many or as few libraries as your team needs, and are automatically shared when you share a notebook.
You can read more about Zepl images in our documentation.
Below I wanted to share a few questions we recently received about how best to use images.
- How should we go about managing our own packages and resolving dependencies – do I build the package somewhere else and then add that as a dependency? Or do we have the ability to code, package and manage libraries within Zepl?
You can manage packages in Zepl through our Image builder. This allows you to build your images all within the Zepl user interface. If you have a requirements.txt file that you use to build your standard Python environments, you can copy these requirements into our image builder.
- How can I get an image with all of the stuff I need so I don’t have to keep doing !pip install every time?
This can also be resolved through the Image builder. I typically advise customers to create a notebook with all of the pip installs for packages and versions they would typically need for a notebook. After you have tested this in the notebook, you can copy those install statements to the image builder.
- I‘ve been so used to GitHub for all development, code reviews etc. – what is the Zepl philosophy or best practice around that?
Version control in Zepl is a slight shift from GitHub. We provide version history for each notebook. Versions in Zepl take a snapshot of the code AND the results of the notebook. The major differences between committing notebooks to GitHub and using Zepl is having the notebook results viewable for each commit and the ability to run your notebook on our containers right where the versions are stored.For code reviews in Zepl, our customers typically lean on the Spaces and Comments feature to provide the required workflow. Typically our customers will set up a Space (shared folder) for Dev, Stage, and Prod. When notebooks are ready for review a user may move their notebook from Dev to Stage and share the link to the notebook with their team. The team members can add comments under each notebook paragraph for suggested edits.
Questions about images? Email us at email@example.com. We’re here to help!