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

Question

Question

What are the differences between a Framework assembly and a non-Framework (i.e. standard UNIX) Python assembly on Mac OS X? In addition, what are the advantages and disadvantages of each?

Preliminary research

Here is the information I found before posting this question:

• [Pythonmac-SIG] Why do I need a Framework for Python?
  • V. Granger: “It seems that I remember that Python requires a Framework assembly if you want to do something with your own Mac GUI. Do I understand this correctly?”
  • S. Barker: "Quite a lot - to access the Mac GUI, the application must be in a suitable set of applications for the Mac. This provides an assembly of the Framework."
• Apple Developer Connection: Platform Definition
  • "A frame is a collection (structured directory) that contains a dynamic shared library along with related resources, such as nib files, image files, and header files. When you develop an application, your project is linked to one or more, for example, iPhone application projects by default tied to the Foundation, UIKit, and Core Graphics frameworks. Your code accesses the infrastructure capabilities through an application programming interface (API), which is published by the framework through its header files. the library is dynamically shared, several applications can access infrastructure code and resources at the same time. The system loads the code and resources of the framework into memory as needed and shares one copy of the resource among all applications. "
• Platform Programming Guide: What is a Framework?
  • "Frameworks offers the following advantages over static libraries and other types of dynamic shared libraries:
    • The structure of structures related, but divided, resources together. This grouping simplifies the installation, removal, and retrieval of these resources.
    • Frames can include a wider range of resource types than libraries. For example, the structure may include any relevant header files and documentation. You can include several versions of the framework in the same kit. This allows you to be backward compatible with older programs.
    • Only one copy of read-only resources is physically based in memory at any given time, regardless of how many processes use those resources. This resource sharing reduces system memory and helps improve performance.

Background

Prior to Mac OS X 10.6 Snow Leopard, I didn’t think about it, because I just downloaded and installed Python 2.6.2 Mac Installer Disk Image , which is a framework assembly, and I do my business with virtualenv, pip, etc. However, with changes in Snow Leopard to 64-bit, gcc, etc., I noticed some problems that made me want to build / compile Python 2.6.2+ myself from the source, which leads me to my question about the differences and benefits / disadvantages of building Python as a MacOSX infrastructure | Darwin.

Answer 1

You have already indicated all the important advantages of creating a framework (congratulations for the excellent research and reporting!); the only flip side is that it’s more difficult to organize it correctly, but if you take your tips from the examples you provided in the installer, this should be doable.

By the way, what happened to the Python system that comes with Snow Leopard? I have not upgraded from Leopard (a long story ... I have a family-licensed DVD-ROM, but I need Snow Leopard to fix some things before I can update), so I have no first-hand experience., But I know that this is assembly 2.6, and it comes in both 32-bit and 64-bit versions ... so why do you need to create your own frameworks?

Answer 2

There is another difference: usually 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 the source and do not intentionally change this, your libpython has only one architecture. I have had cases where two architectures actually led to problems (at least I believe this was the reason), namely when installing python HDF5 bindings (h5py).

And there is another difference: some tools require the installation of frames. For example, PyQt and, in particular, sip. Although you can 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 option without a frame, but I must say that it also caused me a headache.

Answer 3

If you are going to send your code (if it works on another computer), you better use the system version of python, otherwise your program behavior will be undefined on other machines.

Answer 4

I use Macports in 10.6, which makes it very easy to install multiple versions of python and switch between them and the version of Apple:

 sudo port install python26 sudo port install python_select sudo python_select -l 

The latest version of python26 is 2.6.2, and compiles and works fine on 10.6.1: trac.macports.org/browser/trunk/dports/lang/python26/Portfile

Answer 5

Framework assemblies belong to the root account during installation. The assembly source will belong to the account that installs it. The advantage (and disadvantage) of owning a Python installation is that you do not need to change accounts to change it.

The slight difference is that Framework assemblies are built against the EditLine library. Source assemblies are usually compiled against the Readline library. Depending on which Python library is compiled, 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 good layout for automating the compilation of Python 2.4, 2.5, and 2.6 from source code in Mac OS X, which is explained here . This will be compiled against a custom readline assembly. However, the usefulness of source installation scripts is that you can make additional adjustments to your own Python builds, for example. installing major distributions like virtualenv, or harder to install distributions like PIL.