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