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
--
https://mail.python.org/mailman/listinfo/python-list
