Packaging and deployment of standalone Python applications?

[Laura Creighton]

In a message of Thu, 17 Sep 2015 08:23:52 +0200, Kristian Rink writes:
>Hi Laura;
>
>and first off, thanks bunches for your comment.
>
>Am 17.09.2015 um 00:19 schrieb Laura Creighton:
> >
>> Your problem is likely with the shared library search paths.
>> Different distributions put them in different places.  It's a real
>> pain, and the reason why docker is getting more popular.
>
>Well I thought something like this but then again wondered whether this 
>really would be the cause - after all, Thunderbird, Firefox, OpenOffice, 
>Java and a bunch of other applications that are available as "binary" 
>downloads for "generic Linux" do seem to work on RedHat/CentOS, Debian, 
>Ubuntu without these issues. Are these all statically built? Would this 
>be an option for distributing Python applications, as well?

Mozilla uses a hybrid static and binary build thing.
http://www-archive.mozilla.org/build/static-build.html
and confusingly calls that a static build.

My Java didn't come as a generic Linux download.  I had to use the
debian package.  Same for libreoffice.  I needed a .deb for that.

For instance, if you look at the libre office instructions it first
hops up and down saying you should use whatever your package manager
provides.

https://www.libreoffice.org/get-help/install-howto/linux/

Then it leads to the wiki
which leads to the download page
http://www.libreoffice.org/download/libreoffice-fresh/

If you download from this page you will see that it detects
what sort of linux you are running and gets you a .rmp or a .deb
depending on what you need.  That's 4 choices, because 32 bit and
64 bit is also different.

If it makes a mistake and decides you need the wrong sort of
binary package, you can demand that you get the sort you want.

This will handle most of them, but if you need Gentoo linux you will
have to do something else, and there are undoubtably other linux
versions that don't understand .deb or .rpms

Now go back to the wiki and read
https://wiki.documentfoundation.org/Documentation/Install/Linux
the section Terminal-Based Install

As I warned you, it is a real horror.

>Or, other option: Would it work to, say, use venv, make sure there 
>always is a Python of the same version on the target machine installed 
>(say 3.4), and then distribute "just" the python parts without including 
>the interpreter / binary itself?

Getting a Python of the same version is rarely necessary.
That's not where your problem is.  Except that Python 3.x are not
compatible with Python 2.x, the general rule is that later versions
of Python are backwards compatible with earlier ones.

If you can turn your pure python code into a python package, this
will probably simplify your problem.  But, no promises here.  I
don't know enough about what you are trying to do, and this is only
a general rule of thumb.

>Thanks in advance and all the best,
>Kristian

Here's the PyPy Story.
PyPy is a fast version of Python written in Python.  It has a JIT.
On our download page: http://pypy.org/download.html

These days PyPy is really popular.  So there is a real official debian
package, ubuntu package, red hat package, and a gentoo package and all
the rest.  Which means there is a real human being who is reponsible
for making such things for each distro.  This is a welcome outcome
of being popular.  It wasn't always that way.  We had to make
binaries for wherever we wanted to run (everywhere).

The download page still contains a list of possible binaries.

Linux x86 binary (32bit, tar.bz2 built on Ubuntu 12.04 - 14.04) (see [1])
Linux x86-64 binary (64bit, tar.bz2 built on Ubuntu 12.04 - 14.04) (see [1])
ARM Hardfloat Linux binary (ARMHF/gnueabihf, tar.bz2, Raspbian) (see [1])
ARM Hardfloat Linux binary (ARMHF/gnueabihf, tar.bz2, Ubuntu Raring) (see [1])
ARM Softfloat Linux binary (ARMEL/gnueabi, tar.bz2, Ubuntu Precise) (see [1])
...

Note 1 contains more language about if this is not your exact distro, it will
not work.  We say this all over the place and people still do not get it.

Our binrary list used to be a whole lot longer.
And the situation was impossible.  We couldn't build pypys for every
linux distro on the planet, because we didn't own every one.  So we
were dependent on having happy users make one from source, and giving
it to us.  Which people did.  But it meant that every time we made
a release we had to spend forever talking to people over irc or on
the mailing list who couldn't get the source build to build.  Make
a symlink here, make a symlink there.

When you add to the mix that building pypy, starting with CPython instead
of an earlier version of PyPy can grind away for 3 hours and then fall
flat over when you first try to run it because you didn't get the dependencies
quite right ....

It was nothing but pain.

So when docker came out, we jumped at the chance to get out of this mess.
It worked.  We're deliriously happy with the result.
And now we have portable binaries that run anywhere.
Armin Rigo (I think) figured out how to hack the RPATH to get it to work
most everywhere.  I am not sure how that goes, but Armin will
either explain it to you or point you at the correct document to
read if you ask.  He's very nice that way.

see:
https://github.com/squeaky-pl/portable-pypy#portable-pypy-distribution-for-linux

Wish I could be more encouraging,
Laura