Opened 13 years ago

Closed 13 years ago

Last modified 12 years ago

#13626 closed enhancement (wontfix)

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

Reported by: mdickens@… Owned by: macports-tickets@…
Priority: Low Milestone:
Component: ports Version: 1.6.0
Keywords: Cc: mdickens@…
Port:

Description

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

Attachments (1)

py25-wxpython_Portfile.diff (548 bytes) - added by mdickens@… 13 years ago.
Diff of py25-wxpython Portfile to allow for the use of built-in Python 2.5 in Leopard

Download all attachments as: .zip

Change History (9)

Changed 13 years ago by mdickens@…

Attachment: py25-wxpython_Portfile.diff added

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

comment:1 Changed 13 years ago by jmpp@…

Milestone: Port Enhancements

comment:2 Changed 13 years ago by ryandesign (Ryan Schmidt)

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

comment:3 Changed 13 years ago by afb@…

Resolution: wontfix
Status: newclosed

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

comment:4 Changed 13 years ago by 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.

comment:5 Changed 13 years ago by 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.

comment:6 Changed 13 years ago by 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.

comment:7 in reply to:  5 Changed 13 years ago by 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.

comment:8 Changed 12 years ago by (none)

Milestone: Port Enhancements

Milestone Port Enhancements deleted

Note: See TracTickets for help on using tickets.