Thread: [Pyobjc-dev] PyObjC and OSX versions
Brought to you by:
ronaldoussoren
From: David B. <db3...@gm...> - 2010-03-23 06:54:11
|
I originally developed an application when Tiger was mainstream and PyObjC 1.x still current. For a long time now I've mastered my distributions on a 10.4.10 Tiger system with PyObjC 1.4, and had no problem with people running them on 10.4, 10.5, and even 10.6 systems. I even prevented the 10.4.11 update from installing on my build machine since it would have broken a WebKit interface I used. Realizing that there were issues using PyObjC 2.x and trying to have something that could run on Tiger, I didn't plan on changing the process any time soon, and just watched the various threads here about those issues pass by. However, my build system's disk died a horrible death last week. While I'm in the process of rebuilding, I took it as a sign and figured I should bite the bullet and start experimenting with more recent build tools. So I've got a 10.6.2 Snow Leopard system that I've been testing as my next build system. In looking around though, I'm not having a lot of luck trying to find a decent explanation of how to best serve a varied customer base from a 10.6 development system. I know I need PyObjC 1.4 to target Tiger, but can I build/use that on my 10.6 system? And will my PyObjC 2.2 build under 10.6.2 work under 10.5 systems (I don't have any handy to test)? Is there is reasonable summary of the pieces and host platforms needed to support clients with a mixture of 10.4-10.6 systems? Is it easier if I exclude 10.4, or is 10.5 just as hard if you're using a 10.6 build system? I assume sticking with 32-bit is best (and not an issue for me). In some initial trials, I'm sticking with the system Python 2.5.4, 32-bit mode. Looks like the system PyObjC is 2.2b3. I expect that in a final setup, to maintain better control, I'd install a local python (probably still prefer 2.5.x for now due to other libraries) and my own PyObjC/py2app. Aside from running into an issue with QtKit - wish I had caught up to this list sooner since it was the same movieWithAttributes parameter issue where it had to be an NSDictionary mentioned recently - things seem fine on 10.6 systems. As expected, it doesn't even get off the ground on a 10.4 system. Not sure about 10.5 (don't have one to test on). Just wondering what best practices are to create an application that has the ability to run on as many client OS releases as possible, or at least know how many different builds I have to create. Thanks for any pointers or information. -- David |
From: Ronald O. <ron...@ma...> - 2010-03-25 10:33:49
Attachments:
smime.p7s
|
On 23 Mar, 2010, at 7:53, David Bolen wrote: > > In looking around though, I'm not having a lot of luck trying to find > a decent explanation of how to best serve a varied customer base from > a 10.6 development system. I know I need PyObjC 1.4 to target Tiger, > but can I build/use that on my 10.6 system? And will my PyObjC 2.2 > build under 10.6.2 work under 10.5 systems (I don't have any handy to > test)? 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. I hope to find time to do that once current cleanup and py3k work is finished, I want to look into the 10.4 port then as well. Last time I checked PyObjC 2.2 mostly, but not entirely, worked on 10.4. Ronald |
From: David B. <db3...@gm...> - 2010-03-25 20:28:48
|
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 |
From: Ronald O. <ron...@ma...> - 2010-03-30 13:02:51
Attachments:
smime.p7s
|
On 25 Mar, 2010, at 21:28, David Bolen wrote: > > 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). NibClassBuilder shouldn't be used in code that's developed on OSX 10.5 or later, the latest tools no longer generate the metadata that is used by this module. Futhermore Xcode on OSX 10.5 or later knows enough of Python and PyObjC to take away the need for NibClassBuilder. Ronald |
From: David B. <db3...@gm...> - 2010-03-30 19:34:15
|
Ronald Oussoren <ron...@ma...> writes: > NibClassBuilder shouldn't be used in code that's developed on OSX > 10.5 or later, the latest tools no longer generate the metadata that > is used by this module. Futhermore Xcode on OSX 10.5 or later knows > enough of Python and PyObjC to take away the need for > NibClassBuilder. Hmm - it sounds like you're saying not just take away the need for but preclude the use of. I assumed that if I'm developing on 10.5, but still using PyObjC 1.4 to target a 10.4 client that I still need to use the older approach and include NibClassBuilder. It sounds like you're saying that building a UI with 10.5+ tools no longer works with NibClassBuilder at all, so if I need to change the UI, for the application to continue working on 10.4, I need to edit the UI using 10.4 tools? Or will a nib generated with 10.5+ tools still be usable under PyObjC 1.4 just without the need for NibClassBuilder? I made a small test change to an existing nib file while on 10.6 and it seemed to continue to work, but I didn't test it exhaustively. Existing nibs built under 10.4 are fine, but obviously they would have the meta data. -- David |
From: Ronald O. <ron...@ma...> - 2010-04-01 08:16:22
Attachments:
smime.p7s
|
On 30 Mar, 2010, at 21:33, David Bolen wrote: > Ronald Oussoren <ron...@ma...> writes: > >> NibClassBuilder shouldn't be used in code that's developed on OSX >> 10.5 or later, the latest tools no longer generate the metadata that >> is used by this module. Futhermore Xcode on OSX 10.5 or later knows >> enough of Python and PyObjC to take away the need for >> NibClassBuilder. > > Hmm - it sounds like you're saying not just take away the need for but > preclude the use of. I assumed that if I'm developing on 10.5, but > still using PyObjC 1.4 to target a 10.4 client that I still need to > use the older approach and include NibClassBuilder. You don't. NibClassBuilder is just a nifty trick to avoid having to define classes, outlets and actions manually in two places. On OSX 10.4 Interface Builder doesn't know anything about Python, which means you have to declare all classes you want to use in that version of IB inside the NIB file. NibClassBuilder.AutoBaseClass is magic base class that reads information about the class from the NIB file and sets up the right superclass and outlets (as defined in the NIB). In OSX 10.5 (or later) Interface Builder does know how to read Python files, which means you can define the classes in Python and read the definitions in IB. IMHO that results in much easier to understand code because you don't have to hunt down information when you read the code. As an additional snag (sp?) IB on 10.5 won't even create the file that NibClassBuilder uses to determine the superclass and outlets, which means that NibClassBuilder cannot work there. IB might write the additional metadata when you use .nib files instead of .xib files on OSX 10.5, but both will be compiled to a more compact .nib file by Xcode when you build the application bundle. Note that all of this is just a matter of developer convenience: if you want to develop on both platforms you can always define the classes both in IB and the python code. That works just fine, but means you have to do a little more work when changing classes. W.r.t. 10.4 support in general: I'd say that it is more worthwhile to work on porting PyObjC 2.2 to 10.4 than to try to create a workflow using both PyObjC 1.4 and 2.2. For the most part this entails adding #ifdef guards in the C modules to ensure that the wrappers for APIs that aren't available on 10.4 get excluded from the build when building using the 10.4 SDK. Ronald |
From: Aahz <aa...@py...> - 2010-04-03 13:41:26
|
On Thu, Apr 01, 2010, Ronald Oussoren wrote: > > W.r.t. 10.4 support in general: I'd say that it is more worthwhile to > work on porting PyObjC 2.2 to 10.4 than to try to create a workflow > using both PyObjC 1.4 and 2.2. For the most part this entails adding > #ifdef guards in the C modules to ensure that the wrappers for APIs > that aren't available on 10.4 get excluded from the build when > building using the 10.4 SDK. That still means it's going to be tricky writing an app that uses FSEvents on 10.5+ that works without FSEvents on 10.4 -- instead of maintaining separate installs of PyObjC 1.4 and 2.2, I'll need to have separate installs of 2.2 and 2.2, and keeping track of which is which will be more difficult. Perhaps I'm missing something? Would it be possible to build PyObjC 2.2 on 10.5 in a way that works on 10.4, just with FSEvents disabled? There's a reasonably good chance we're going to switch to kauth due to FSEvents' limitations, which would sidestep the issue another way. Does anyone have any experience using kauth? Before someone asks, kqueue is not sufficient for our needs (monitoring directory systems that might have a million files), and pnotify has languished for so long without update that I'm not willing to take a chance with it. I think that pretty much exhausts the available options. -- Aahz (aa...@py...) <*> http://www.pythoncraft.com/ Why is this newsgroup different from all other newsgroups? |
From: Ronald O. <ron...@ma...> - 2010-04-04 09:51:29
Attachments:
smime.p7s
|
On 3 Apr, 2010, at 15:41, Aahz wrote: > On Thu, Apr 01, 2010, Ronald Oussoren wrote: >> >> W.r.t. 10.4 support in general: I'd say that it is more worthwhile to >> work on porting PyObjC 2.2 to 10.4 than to try to create a workflow >> using both PyObjC 1.4 and 2.2. For the most part this entails adding >> #ifdef guards in the C modules to ensure that the wrappers for APIs >> that aren't available on 10.4 get excluded from the build when >> building using the 10.4 SDK. > > That still means it's going to be tricky writing an app that uses > FSEvents on 10.5+ that works without FSEvents on 10.4 -- instead of > maintaining separate installs of PyObjC 1.4 and 2.2, I'll need to have > separate installs of 2.2 and 2.2, and keeping track of which is which > will be more difficult. > > Perhaps I'm missing something? Would it be possible to build PyObjC 2.2 > on 10.5 in a way that works on 10.4, just with FSEvents disabled? That's pretty easy to do, although I don't recall if I have prepared the code for it. This basicly requires weak-linking to any symbols that aren't available on 10.4 and dealing with the NULL pointers that you might get because of that. An example of this is Modules/posixmodule.c in the python tree. That uses weaklinking to ensure that os.lchown (and several other symbols) are present on OSX releases that have it while still working on older OSX releases. > > There's a reasonably good chance we're going to switch to kauth due to > FSEvents' limitations, which would sidestep the issue another way. Does > anyone have any experience using kauth? What's kauth? > > Before someone asks, kqueue is not sufficient for our needs (monitoring > directory systems that might have a million files), and pnotify has > languished for so long without update that I'm not willing to take a > chance with it. I think that pretty much exhausts the available options. Ronald > -- > Aahz (aa...@py...) <*> http://www.pythoncraft.com/ > > Why is this newsgroup different from all other newsgroups? > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Pyobjc-dev mailing list > Pyo...@li... > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev |
From: Aahz <aa...@py...> - 2010-04-05 21:41:31
|
On Sun, Apr 04, 2010, Ronald Oussoren wrote: > On 3 Apr, 2010, at 15:41, Aahz wrote: >> >> There's a reasonably good chance we're going to switch to kauth due to >> FSEvents' limitations, which would sidestep the issue another way. Does >> anyone have any experience using kauth? > > What's kauth? Hooks for virus scanners to detect filesystem changes. I believe it's the underlying mechanism for FSEvents: http://developer.apple.com/mac/library/technotes/tn2005/tn2127.html -- Aahz (aa...@py...) <*> http://www.pythoncraft.com/ Why is this newsgroup different from all other newsgroups? |