[gentoo-alt] On Python and OSX

[Fabian Groffen]

This message is mainly for Mac OS X users, if you're not one of them,
you can probably just skim or even ignore this message.

Over the last few weeks I've been messing/fighting with Python for the
"aqua" USE-flag that I added to it.  Enabling this flag causes a
framework build of Python to be made.  This actually results in a
Mach/Next-style installation hierarchy, referred to as a Framework.  On
OSX these are used and typically found in /Library/Frameworks.
Basically, with Gentoo Prefix you *never* want such thing to be
installed in your prefix, for it's useless within the UNIX-style
environment that we built.  So basically, one would wonder why we would
like to build Python like this.  The answer is that if you want to do
graphical stuff with Python, e.g. applications using wxPython, then you
need a Python that is bound to the Mac OS X window system using
CoreGraphics and all the Aqua-related Apple candy.  The crux is here,
some stuff only works right if the binary itself from a framework.  So,
that's the main reason we want a framework build of Python.  For this to
get it right, I've got some inspiration from our friends at MacPorts.

Over the past few weeks a few mess-ups, have been made, causing the
interrevision bumps of python.  Sorry for all the rebuilding.

The changes I've made are as follows.  First, because we need the
framework and since we don't want many more frameworks, I decided to
install the framework in a non-standard location, which better suits our
UNIX-layout: $EPREFIX/usr/lib/Python.framework.  This in contrast to
$EPREFIX/Library/Frameworks/Python.framework.  Using the former part, we
hide the framework thing a bit, by partially swiping it under the carpet.
Next, I've heavily crippled the framework build of Python to make it
more like a UNIX build.  This is necessary to make sure for instance
that applications can still find python includes, python modules, etc.
where they expect them to be.  Also for the upgrade path the directory
locations should remain the same, e.g. not suddenly be inside the
framework.  To achieve this, multiple patches and iterations were
necessary, as Python has the bad habit to try to be smart at the
occasions where it should better not.

By default, a framework build of python supplies usr/bin/python and
/usr/bin/pythonw which are in fact small executables which call the
pythonw executable from the framework to achieve the desired effect of
being in the framework and thus having access to the graphical
environment.  I didn't like this, expecially not because this means you
always run the framework python, and due to Python's own "cleverness"
that means you get e.g. a pythonpath that is using that framework
location instead of your usr/lib/pythonxx/site-packages.

What I therefore did is make the "python" executable in usr/bin really
be the python interpreter that cannot do graphical stuff, like it used
to be before, and bind pythonw to the framework python.  pythonw is not
our invention, it's the way by upstream to get access to the python with
graphical capabilities on a Mac and Windows.  So, are we happy?  Yeah,
because pythonw does quite a good job to run wxPython stuff on OSX with
Prefix now, it seems.

At the same time as this was taking place, we also did fixes for 64-bits
framework build Python on Leopard, and 32 or 64-bits build Python on
Snow Leopard.  That said, it should compile fine on Snow Leopard now.
And by the way while we were fixing things, we also fixed readline
support on the console, which was disabled for as long as I recall
because of some stupid "typically Python" decision.

So, I guess everyone is up-to-date again now.


-- 
Fabian Groffen
Gentoo on a different level