Allow for the use of built-in Python 2.5 in Leopard

[mdickens@…]

Since Leopard comes with Python 2.5.1 installed, why not create a variant allowing for the use of this built-in python? I've created an example using py25-wxpython, and will attach the Portfile diff that does this. Also note that I've added a post-destroot command to create links which allow for python to import the provided wx properly (separate issue).

[mdickens@…]

Diff of py25-wxpython Portfile to allow for the use of built-in Python 2.5 in Leopard

[ryandesign (Ryan Carsten Schmidt)]

In general, MacPorts deliberately does not use system libraries/binaries. Please read the FAQ.

[afb@…]

This issue is not specific to Leopard, as Panther and Tiger also has ​packages... But it's by design.

[mdickens@…]

My original purpose was to allow anyone to use the built-in Framework install of Python 2.5.1, since MacPorts (still) doesn't provide one - and the Framework version is what I (and others) require to do our work. I can understand why MacPorts doesn't make use of most of the built-in Apple-provided libraries / binaries, but it's always good to have an interim solution while MacPorts catches up.

[mww@…]

The framework build of Python is not required for anything. It is just that someone upstream decided that IF you want the pythonw wrapper (etc.) you HAVE TO build a framework. Unfortunately it is a pain to un-framework-ify Python, not clear how to set which architectures to build for (x86_64???) etc.;
The problem is the mindboggingly configuration setup IF you enable the framework build. If you add -enable-framework, you get hit by hard-coded stuff. If someone would mind fixing this, we could all be happy.

[mdickens@…]

Ummm ... I really don't follow you. When I configure Python with -enable-framework, assuming I have my shell environment setup correctly, then I get a framework install that works just fine ... pretty much the same as what Apple provides AFAICT. Could you explain why one would want to un-framework-ify a framework on MacOS X, where frameworks are the norm? Could you also explain the "hard-coded stuff" to which you refer? How does one in OSX decide which architecture to build for? Can we even choose between x86_32 and x86_64? If I can understand what your issue are, I might be able to help out.

All of that said, has anyone tried out the tarball I provided for ticket #11267? In my testing, it provides a Python install correctly on Darwin 8 and 9, framework or no framework (but not both). For what I do, I require the GUI-capable Python - which if that means I have to have a framework, then I'll figure out a way to make it happen ... which, I thought, is what I did.

[mdickens@…]

Replying to mww@macports.org:

The framework build of Python is not required for anything. It is just that someone upstream decided that IF you want the pythonw wrapper (etc.) you HAVE TO build a framework. Unfortunately it is a pain to un-framework-ify Python, not clear how to set which architectures to build for (x86_64???) etc.;
The problem is the mindboggingly configuration setup IF you enable the framework build. If you add -enable-framework, you get hit by hard-coded stuff. If someone would mind fixing this, we could all be happy.

Is it your desire to allow for GUI-capable Python without the Framework? Why would one want to do that, when the Framework version works just fine the way it is? So what if the 'include's and 'lib's are installed in a 'strange' location ... Apple's GCC handles that just fine with the '-framework' flag. Why fix it if it ain't broke?

In working on the latest python25 port tarball in ticket #11267, I think it is possible to create variants for doing 32-bit or 64-bit application / libraries (or both), using the "-arch" option in Apple's GCC. I believe that everything is controller by the top-level 'configure' script, which can easily be patched for different '-arch' types ... but this would then require +universal variant to work ... which requires some patches in Darwin 9 / OSX 10.5.

[(none)]

Milestone Port Enhancements deleted