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

Answer 1

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 2

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.