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?
It's not unable to migrate, it's more like, we want to move to the new Python and still support apps written on the old version while we're working with the new version, and maintain two Pythons at the same time until we have all our internal Python modules on the new Python. This is for desktop apps for internal users (non-developers, like artists). And with Python, you can't share binary modules, or it's not recommended to do that. Another use of MacPorts was to build a portable application on a portable Firewire/USB drive with a local MySQL database and PHP web site. In that case, we just put an entire MacPorts build under /Volumes/SOMENAME/MacPorts and then launch MySQL, Apache, and a py-wxwidgets app from there that would talk to MySQL and the web site. We recently changed the mount point name and hence needed to recompile everything and that's when we found the py-wxwidgets breakage. 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?
It's not the Python as much, as most modules are easily moved to the new version. It's more, some py-* ports are moved from 2.4 to 2.5, so you have an incomplete set of packages for a Python version. But in our portable application, we built the entire MacPorts into /Volumes/SOMENAME on 10.3 and we run it on 10.4 just fine (even on i386, which is nice).
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.
No, I would like to see Python 2.5 in Leopard. No better time to move to 2.5. My concerns are just with the MacPorts' Pythons, as for MacPorts, I count on its version of Python, not the OSes. Do you work for Apple? I see your email address as a non-Apple one. Regards, Blair