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/libc.so.6: 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 https://www.vagrantup.com/
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.
Christian
--
https://mail.python.org/mailman/listinfo/python-list
