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.
Answers:
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?
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
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.
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.
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.
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.”
- “Frameworks offer the following advantages over static-linked libraries and other types of dynamic shared libraries:
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?
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
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.
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.
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.