There are many options to package software, particularly Python software. How do all these options fit together, and how does one decide which option is right for them? This guide takes a holistic approach, as presented at PyBay 2017.
A backpack at least California? A carry-on bag The USA? A suitcase, or maybe an RV Otherwise? Any of the above — and a passport The Packing Gradient How far you travel influences what you pack low size high portability
A network connection, probably to the Internet ⊡ Preinstalled system libraries ⊡ Build tools for target packages (gcc/clang) • For when wheels aren’t available for your platform Standard pip installation requires:
/ etc. Installation requires Linux / Mac / Windows Executable or double-click install System libraries Distribution options Direct download App stores Freezers represent the best option for consumer software.
⊡ Chef Omnibus ⊡ Higher-level self-containment ⊡ Copies of all dependent services ⊡ Case Study: GitLab □ https://about.gitlab.com/installation/ □ https://gitlab.com/gitlab-org/omnibus-gitlab Freezers (EE) Packaging Python Applications
Installation requires Debian-/RedHat-based Linux yum or apt Minimal system libraries Distribution options Direct download PPA / package repo Omnibus could probably ship a script, but works best for applications with multiple components (services, queues, batches)
On their own, not so great for users ⊡ Example: dh-virtualenv □ Analogous to PEX: includes libraries, but not Python □ Artifacts managed by your Debian package manager Many technologies, many more part than whole.
Linux (or equiv. virtualization) Container runtime “Pull” step Distribution options Linux app store Docker Hub/Registry Containers might be overkill for our script, but it wouldn’t top the charts for the most ridiculous image to date.
of creating a distributable software artifact ⊡ A packaging design is not the last phase in a project ⊡ Python is general purpose, PyPI and pip are not ⊡ Because libraries are different than applications