Packaging and deployment of standalone Python applications?

[Kristian Rink]

Hi Laura;

and first off, thank you very much for your very insightful response. 
Some thoughts on that:

Am 17.09.2015 um 11:06 schrieb Laura Creighton:
>
> 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.

Ah ok. I haven't looked too deep into Mozilla or LibreOffice, but I know 
there are Firefox Linux und Linux 64bit downloads that, once unpacked, 
will run on Debian, Ubuntu, Fedora and any other distribution I tried so 
far. In LibreOffice, we do have some bundle (we didn't built ourselves) 
living somewhere in /opt, being copied to various production machines 
and this, too, runs on Debian and on CentOS without issues. I do have 
LibreOffice (off the Ubuntu ppa) installed on my workstation, but not on 
the production environment also because the LibreOffice in the Ubuntu 
repos, as far as I can tell, will pull X as dependency while we run 
headless servers.

Similar about Java - here, at least in Ubuntu or Debian, in some 
situations I used Debian facilities to create deb packages out of the 
official Java download which is either an rpm or a tgz. That's why I 
wondered in the first place: In our current deployment of (Java) 
services, the Java runtime gets bundled with the service for some 
systems, zipped, moved to the host and started there. This works well 
across all Linux systems, as long as they are 64bit so far.

That's why I tried doing the same for Python and initially thought about 
this in the first place. ;)


[LibreOffice]
> 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.

Well - yes, but have you so far tried unpacking, say, the rpm manually 
and running the files in there on Debian? Also, it's interesting to see 
they "just" make a difference between deb and rpm (32bit and 64bit of 
course). This would end up with the same deb being installed to Debian 
or Ubuntu - which works, while copying a Python interpreter binary from 
an Ubuntu to a Debian machine obviously doesn't seem to work. So in some 
ways they *do* get some sort of portability in this... ?


>
> 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.

I will have a look at this, then, thanks. :)


So far, this morning I followed the venv approach, created a venv 
locally on my Ubuntu development workstation, made sure to have the same 
python version (3.4) installed on the server (built from source in 
Debian), and then copied the whole venv structure (including my 
application) to that machine, replacing only the link to the python 
binary in the venv (which lives in /usr/local on the Debian system).

So far this works, and if this generally would work, it seems an 
acceptable way to me. :)


> PyPy is a fast version of Python written in Python.  It has a JIT.
> On our download page:http://pypy.org/download.html

Neat. I just read about it but so far never actually used it. In our 
environment, Jython is pretty familiar (because mostly we're still a 
Java house and Jython integrates rather well with Java), but PyPy is 
interesting, definitely.


> 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.
>

I will have a look at this and happily get back to this if it will 
become necessary. :) Two things come to mind, however (feel free to take 
this off list as I am unsure whether this still relates to Python):

(a) Why is distributing PyPy so difficult, after all? From where I 
stand, by now I see this a "Python implementation on top of Python". How 
does this relate to (C)Python? How much of the PyPy core is actually 
platform dependent?

(b) How did / does Docker help you here? So far I just experienced 
Docker as a solution to easily manage loads of virtual machines on top 
of certain machine templates; I haven't made much use of it so far 
nevertheless...

Thanks very much anyway, all the best!
Kristian