Re: [Pyobjc-dev] PyObjC and OSX versions

[David B. <db3...@gm...>]

Ronald Oussoren <ron...@ma...> writes:

> Building pyobjc for running on various OS releases is too hard at
> the moment. PyObjC 2.2 build on 10.6 won't work on 10.5 at the
> moment due to a dependency on libxml. I have removal of that
> dependency on my todo list, but haven't gotten around to doing that
> yet.

Thanks, that's helpful to know.  And thanks also to Aahz for some
offline pointers to his recent posts.  Sounds like the safest thing,
if using current releases of PyObjC and especially without a full
complement of test machines, is just to assume that something built on
system 10.w.x will only work on 10.y.z where y.z>=w.x.  So continuing
to build with PyObjC 1.4 for 10.4 seems safest for supporting any of
10.4-10.6 clients for now.

For anyone else reading this down the road who may be interested, I
ran into various strange failures initially trying to use the older
tool versions with more recent Python interpreters and libraries under
10.6.  Backing off to PyObjC 1.4 alone generated errors from
NibClassBuilder.extractClasses() trying to load my main nib (something
Aahz also remarked on in his post).  After also backing off to py2app
0.3.6, it then failed to run when python 2.5.4 couldn't find a config
header that hadn't been included in the bundle.  So the older py2app
solved the nib problem but clearly was missing a change in bundling
needed by the later Python.

I also ran into different behavior for existing code when building
with PyObjC 2.2 directly for 10.6 execution.  I'd have dismissed it as
expected API changes across two major OSX releases, except that
applications built under PyObjC 1.4 - even when built on the same 10.6
system - didn't exhibit any of the issues.  So there must be something
different in how the later PyObjC/py2app tools bundle things or
identify the bundle to the OS that affects runtime behavior.

For example, some key/observer calls - deprecated as of 10.5, but the
only option when running on 10.4 - seem to stop working, but only when
built with PyObjC 2.2.  The same code/calls when running the bundle
created with PyObjC 1.4 (whether previously or on the same 10.6
system) work fine.  And even under 10.6, the call is documented as
being supported, albeit deprecated, for backwards compatibility.
Similarly for the issue recently posted about on 10.6 where
QTMovie.movieWithAttributes_() requires an NSDictionary and not just a
Python dict - but my 10.4 bundle which uses a Python dict continues to
run fine on the same 10.6 system.

Clearly there's night and day differences between PyObjC 1.4 and 2.2
so I can't claim to be completely surprised, but I do find it
intriguing that the issues a 2.2-built bundle exhibit aren't present
when running on the same system with bundles built with 1.4.

Anyway, I finally resorted to restoring the entire private Python
framework tree (including Python 2.5.1) I had been using on my 10.4
system onto my 10.6 system and am using that.  It appears to build my
application properly such that it still runs on 10.4 and behaves the
same with respect to the API calls as it always has.  So the
combination of Python 2.5.1, PyObjC 1.4, and py2app 0.3.6 seems to work
even when the host environment is 10.6.

It's unfortunate that there are so many version requirements amongst
OSX and PyObjC releases (and fuzziness in terms of knowing what those
requirements are) with respect to host and target OSX environments.
Given my experience running the 10.4-built bundles on later systems,
the backwards compatibility in OSX itself is quite good, but clearly
using a later system to create something an earlier system can run (or
even to build legacy code) is harder to lock down.

Then again, I'd hate not to have PyObjC even with these constraints,
so don't wish to sound like I'm complaining too much - I really
appreciate all the hard work that has gone into PyObjC.

-- David