Packaging and deployment of standalone Python applications?

Christian Gollwitzer auriocus at
Thu Sep 17 09:24:35 CEST 2015

Am 16.09.15 um 21:29 schrieb Kristian Rink:
> Thanks, this already is pretty close to what I need. Playing with this
> and virtualenv, I figured out that this way it's pretty easily possible
> to have isolated Python environments _locally_. However I failed to
> package one of these environments and move it to, say, from my Ubuntu
> development host to a remote Debian server, I end up with errors like
> these while trying to run the Python off the environment on that host:
> /lib/x86_64-linux-gnu/ version `GLIBC_2.14' not found

This is a typical problem on Linux when moving binaries between 
different distributions. The libc is the most basic library, used by 
programs compiled from C (virtually everything). Fortunately it has a 
very good version management which makes it backwards compatible.

Have you compiled everything from source? The solution is to compile 
everything on the oldest machine which you can get hold of. If you want 
portable binaries on Linux, I suggest that you carry along with your 
program all shared libraries except libc & friends (libm, 
libstdc++,...), which really are part of the operating system, and to 
setup a VM with an old libc6-distribution where you compile your stuff. 
For instance try Ubuntu 10.04 LTS. There is a nice management tools for 
these VMs called Vagrant

If you think, that this is lots of tedious work, you are right - 
deployment is hard work. Ideally, you would have Python installation 
that can be carried along as a binary directory and in variants for all 
major OSes.

In the case of the Java VM this is just easier because somebody else 
already did the hard work. On Windows, I used PortablePython in the past 
for a similar project, but this is gone. Another possibility is 
ActivePython, but I think the free license does not allow to carry it to 
other computers - in principle it could work.

IMHO this is one of the lacks of CPython. Distributing source is not 
always practical, especially if the project involves modules written in 
C, or a large number of 3rd party libraries. To provide linux binaries 
as .rpm and .deb, as suggested elsewhere in this thread, is even more 
cumbersome than binaries in this case - you'd have to set the right 
dependencies for a huge variety of distributions, such that the package 
manager pulls, e.g. "python-pillow" on one distro and "libpillow" on 
another etc. A well maintained portable distribution for all major 
platforms could substantially ease that out.


More information about the Python-list mailing list