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

Question

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 advanta

Answer 1

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.

Answer 2

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.

Answer 3

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?

Answer 4

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.

Answer 5

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