We Keep Coding

Does python + pyinstaller support multiple OS/Versions of linux?

I have written several small scripts in python and build the binaries using pyinstaller.
When I would build them on my Ubuntu 16.04 machine -- they would run fine on the machine where I build them. But moving the file to a Centos / Redhat 7.4 machine would give me GCLIB and other .so version dependency errors.
Building the same binary on docker with the same version of Centos would not give these errors.
If I try running the binary compiled on Centos 7.4 on Centos 6.6 I would get errors again -- But building on Centos 6.6 it would work correctly with Centos 6.6
I have solved the problem using a lower version of Centos to build my binaries for now.
My specific question is -- In Python, is it a common approach of building the binaries on different OSs based on the target OS that it is intended for (assuming linux targets only) or what I am doing is a hack / bad way of solving this problem?
I am trying to understand how this problem is approached in the standard way.

As long as the binary produced by pyinstaller only depends on glibc, then it should be a valid approach to build it on the oldest system available, and it should work on future systems.
In general, glibc is designed to be backwards compatible, so that applications built against an older version of glibc will still run with a newer glibc, but not vice versa. It does this via symbol versioning, in which each symbol you link to can have a version associated with it, and any case in which a newer glibc has changed the ABI of some function, it will also have a compatibility routine with the old ABI exposed with the older symbol version, so that applications linked against the old one will dynamically link with the compatibility routine, while if you have an application linked against the newer symbol versions, there won't be the newer versions in an older glibc to dynamically link to.
While other libraries can also do this, not many library authors bother to, so newer versions may simply be incompatible, while the glibc developers generally try to preserve compatibility.
So yes, as long as the final binary links only to glibc, or to other libraries which follow a similar symbol versioning scheme to ensure that older binaries will still link properly to newer versions of the library, it is perfectly valid to build against an older version and then run it on newer versions of various Linux distros, and even generally across distros as well.
Unfortunately, there's no good way to get the linker to pick the older symbol versions if linking against a newer glibc, so frequently the easiest way to do this is within a Docker or other type of container containing an older distro that has the oldest glibc that you want to be compatible with.

Will Python programs created on a Raspberry Pi running Raspbian work on a Windows 8.1 machine?

I would like to use my Raspberry Pi for some programming. (never done it before, I want to get into Python.) If I can transfer my programs yo my Windows 8.1 computer and run them there also, that would be perfect. Can I do that? Thanks!

Yes! Python code is mostly platform independent. Only some specific libs must be compiled in the Maschine. These should be installed using pip (if needed). More info in Google.

Short answer: Yes.
Long answer: That is the whole point actually. Just make sure you install proper python version on your Windows machine, and set up path properly in order to be able to start your python scripts globally. Here is a nice resource - https://docs.python.org/2.7/using/windows.html. Once you set it up, you just need to transfer your .py files from Raspberry Pi to Windows machine.

Short answer: mostly yes, but it depends.
Obviously, the Raspberry Pi specific libraries for controlling its peripherals won't work on ms-windows.
Your Pi is probably running a Linux distribution that has package management and comes with a functioning toolchain. That means that installing (python) packages and libraries will be a breeze. Tools like pip and setup.py scripts will mostly Just Work.
That is not necessarily the case on ms-windows.
Installing python libraries that contain extensions (compiled code) or require external shared libraries is a frustrating epxerience for technical reasons pertaining to the microsoft toolchain. On that OS it is generally easier to use a python distribution like Anaconda that has its own package manager, and comes with packages for most popular libraries.
Furthermore, if you look into the documentation for Python's standard library you will see that sometimes a function is only available on UNIX or only on ms-windows. And due to the nature of how ms-windows creates new processes, there are some gotchas when you are using the multiprocessing module.
It would be a good idea to use the same Python version on both platforms. Currently that would be preferably 3.6 or 3.5.

GTK3 and Python3 on Windows?

Is there any way to launch a Python3 / GTK3 based application on a Windows machine? It seems that this is not that simple as with GTK2/Python2.
Thanks a lot,
Thomas

I hope, i understand the question. You Need a actual runtime of gtk3 on Windows.
inofficial gtk3.14.13 64bit-Runtime, 32bit here not available,
see:
https://github.com/tschoonj/GTK-for-Windows-Runtime-Environment-Installer
win32 and win64: experimental official runtime 3.6.4 in http://www.gtk.org/download/index.php
is very Alpha or beta.
I hope this helps enough for gtk3.

As far as I know, there are still no official GTK3 or GObject-Introspection libraries for Windows, and so there are no python bindings.

I'm assuming you want the development kit. Windows version has indeed been missing for a long time, but there's some available now.
Going to official site and finding https://wiki.gnome.org/Projects/PyGObject, you can find a link to "Windows installers" which should lead to a rather massive all-in-one installer for Gtk3 and many related libraries for Python 3. You can load a current cpython from https://www.python.org/downloads/ and install that first.
For windows, there's also a lot of unofficial pre-built packages in http://www.lfd.uci.edu/~gohlke/pythonlibs/. Cpython 3.4 at least seems to include a functional pip for installing wheels.
I've made some use of these for running some python and matplotlib code 64-bit windows and they work rather nicely with 64-bit python 3.4. You can test with e.g. http://gtk3-matplotlib-cookbook.readthedocs.org/en/latest/ to find backend settings and other tips.

Running PyObjC application (built in Xcode) on previous version of Mac OS?

I am using Xcode to build a PyObjC application. The app runs fine on the build machine (running 10.8) but crashes on startup on a machine running 10.6, because it fails to find the Python 2.7 installation. Fair enough -- the preinstalled Python on 10.6 is Python 2.5. But I don't really care which Python version my app uses, I just want it to use the latest version of Python it can find.
How can I either:
A) Tell my app to use the latest version of Python available on the host system, OR
B) Bundle the entire Python source into my app?
I have been very frustrated by this issue and any help would be greatly appreciated!

Good question. I wrestled with this for an embedding problem a few years ago and ended up dynamically linking against a specific version that I knew was available on every platform.
I had assumed originally that the Python.framework's Current would be adequate, but it seems to get resolved at link time by Xcode, therefore making the link specific to a particular version. For my purposes, I was able to link directly to
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Python.framework/Versions/2.7/Python
Which works for OS X 10.7 and 10.8. If you need to go back to 10.6, you'll want to try linking to
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/Python.framework/Versions/2.5/Python
Obviously, if you're compiling against the 10.6 SDK, you'll want to use that, but the key is to make sure that you link to a version-specific version of the libraries and not the framework version itself. You should be able to manually navigate to the specific version through the + button in the Link Binary with Libraries, but if you have problems, you can open the Python.framework from the SDK directly in the Finder and drag the version-specific library into the Link Binary with Libraries group.
If you find a way around this, then please post another answer here, but this was effective for me to link for embedding into my app.

Use py2app to create the application bundle, and do that using a separate install of Python (that is don't use /System/Library/Framework/Python.framework). The python install you use should be compiled with the MACOSX_DEPLOYMENT_TARGET set to the minimum OSX release you want to support.
When you do this, it should be possible to deploy to older OSX releases. I regularly do this for building apps on a 10.8 machine that get deployed to a 10.5 machine.
You do need to take some care when including other libraries, especially when those include a configure script: sometimes the configure script detects functionality that is available on the build machine, but not on the deployment machine.
BTW. You need to link against the same version of Python as you use at runtime. CPython's ABI is not compatible between feature releases (that is, the 2.6 ABI is not necessarily compatible with the 2.7 ABI). For python 3.x there is a stable ABI that is compatible between feature releases, but AFAIK that's primarily targeting Python extensions and I don't know how useful that is for embedding Python in your application.

Differences between Framework and non-Framework builds of Python on Mac OS X

Question
What are the differences between a Framework build and a non-Framework build (i.e., standard UNIX build) of Python on Mac OS X? Also, what are the advantages and disadvantages of each?
Preliminary Research
Here is the information that I found prior to posting this question:
[Pythonmac-SIG] Why is Framework build of Python needed
B. Grainger: "I seem to recall that a Framework build of Python is needed if you want to do anything with the native Mac GUI. Is my understanding correct?"
C. Barker: "Pretty much -- to access the Mac GUI, an app needs to be in a proper Mac application bundle. The Framework build supplies that."
Apple Developer Connection: Framework Definition
"A framework is a bundle (a structured directory) that contains a dynamic shared library along with associated resources, such as nib files, image files, and header files. When you develop an application, your project links to one or more frameworks. For example, iPhone application projects link by default to the Foundation, UIKit, and Core Graphics frameworks. Your code accesses the capabilities of a framework through the application programming interface (API), which is published by the framework through its header files. Because the library is dynamically shared, multiple applications can access the framework code and resources simultaneously. The system loads the code and resources of a framework into memory, as needed, and shares the one copy of a resource among all applications."
Framework Programming Guide: What are Frameworks?
"Frameworks offer the following advantages over static-linked libraries and other types of dynamic shared libraries:
Frameworks group related, but separate, resources together. This grouping makes it easier to install, uninstall, and locate those resources.
Frameworks can include a wider variety of resource types than libraries. For example, a framework can include any relevant header files and documentation.
Multiple versions of a framework can be included in the same bundle. This makes it possible to be backward compatible with older programs.
Only one copy of a framework’s read-only resources reside physically in-memory at any given time, regardless of how many processes are using those resources. This sharing of resources reduces the memory footprint of the system and helps improve performance."
Background
Prior to Mac OS X 10.6 Snow Leopard, I hadn't thought much about this, as I simply would download and install the Python 2.6.2 Mac Installer Disk Image, which is a framework build, and go about my business using virtualenv, pip, etc. However, with the changes in Snow Leopard to 64-bit, gcc, etc., I've noticed some issues that have made me want to build/compile Python 2.6.2+ myself from source, which leads me to my question of the differences and advantages/disadvantages of building Python as a MacOSX|Darwin framework.

You've already listed all important advantages of making a framework (congratulations for excellent research and reporting thereof!); the only flip side is that it's harder to arrange to build one properly, but if you take your clues from the examples in the installer you quote, it should be doable.
BTW, what's wrong with the system Python that comes with Snow Leopard? I haven't upgraded from Leopard yet (long story... I do have the "family license" upgrade DVD, but need Snow Leopard to fix some things before I can upgrade), so I have no first-hand experience with that yet, but I do know it's a 2.6 build and it comes in both 32-bit and 64-bit versions... so why do you need to build your own framework?

There is another difference: typically the Framework installation provided by the installer from python.org has several architectures.
$ file libpython2.7.dylib
libpython2.7.dylib: Mach-O universal binary with 2 architectures
libpython2.7.dylib (for architecture i386): Mach-O dynamically linked shared library i386
libpython2.7.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
If you install from source and you do not deliberately change this, your libpython has only one architecture.
I have had cases where the two architectures actually resulted in problems (at least I believe that this was the reason), namely when installing the HDF5 python bindings (h5py).
And there is yet another difference: some tools require the framework installation. For instance PyQt, and in particular sip. While it is possible to install sip and PyQt even for the non-framework version of python, it is much more complicated.
As for the decision what to prefer, I still do not know. At the moment, I went for the non-framework option, but I must say, that it also caused me some headache.

If you are going to ship your code (have it running on another machine), you'd better use the system version of python otherwise your program behavior will be undefined on the other machines.

I use Macports on 10.6, which makes it very simple to install multiple versions of python and switch between them and Apple's version:
sudo port install python26
sudo port install python_select
sudo python_select -l
The most recent version of python26 is 2.6.2, and compiles and runs fine on 10.6.1:
trac.macports.org/browser/trunk/dports/lang/python26/Portfile

Framework builds are owned by the 'root' account when installed. A source build will be owned by the account installing it. The advantage (and disadvantage) of having ownership of the Python installation is that you don't need to change accounts to modify it.
A small difference is that Framework builds are built against the EditLine library. Source builds are usually compiled against the Readline library. Depending upon which library Python is compiled against, the readline module in the standard library works slightly differently. See 'man python' on Mac OS X for more details on this.
There is a nice buildout for automating the compile of Python 2.4, 2.5 and 2.6 from source on Mac OS X, which is explained here. This will compile against a custom build of readline. However, the usefulness of scripting the source install is that you can make additional tweaks to your custom Python builds, e.g. installing essential distributions such as virtualenv, or harder to install distributions such as PIL.