On 22 Feb, 2007, at 20:29, Jordan K. Hubbard wrote:
This has been an interesting conversation, particularly given some of the comments from folks claiming they're facing this scenario in commercial / support scenarios where products are based on (presumably forwards incompatible) Python version x and unable to migrate to Python version y. Do such people simply bundle Python with their applications (I've seen that approach used) or do they rely in Framework versioning support?
I bundle the python framework with applications, anyone that uses py2app will get that functionality for free when he's not using the system version of python.
That's mostly good for backwards compatibility but pretty hosed for forwards compatibility since Apple didn't really take the Framework approach to its fullest and there's really no way to say "I want - framework Foo versionX" at the link stage, compiling newer stuff against older bits (you pretty much have to go to the trouble of keeping back-rev'd copies of MacOSX around for hosting your builds). How does MacPorts help people with this, or does it?
That's not entirely true, you can explicitly link with the dylib inside the framework. That is, '-framework Python' is the same as linking with /Library/Framework/Python.framework/Versions/Current/ Python. It's not as easy as linking a framework, especially when doing this from Xcode, but it's not very hard either.
I ask because we're likely going to go with Python 2.5 for Leopard (not in the seeds yet, but soon) and there's still time to rethink that decision if it's really going to hose people.
I'm +1 on Python2.5 in Leopard. Ronald