I've used fpm to make rpm and deb packages that simply include a virtualenv, it works ok.

One of the significant tradeoffs to this approach is you lose the carefully-crafted tree-of-dependencies that the distros favor, so it makes the package pretty much automatically unacceptable to package maintainers.

However, being able to have install instructions that amount to "yum/apt-get install <package>" is pretty great.

I am hoping for an app/container convergence at some point, but we might need to drop the fine-grained dependency dream and have them be more self-contained, like Mac OS X apps.

FPM is written as an in-house solution only. It's not intended to be used for making packages for official distro repositories for third-party users to pick up, and they suggest you use the distro-specified methods for those.

we use fpm & something like dh-virtualenv along exactly those lines. Helps us manage a complex mix of native/system-level dependencies (non-python) as well as python packages.

We also incorporate a set of meta packages which means we can have multiple codebase versions installed and switch the "active" one by installing the right version of the meta-package. There's also meta-packages for each service running off the same codebase, which deals with starting/stopping/etc.