Re: [Pyobjc-dev] Python rather than ObjC for main?

[<bb...@ma...>]

On Friday, November 8, 2002, at 09:38 PM, Peter Montagner wrote:
> On Saturday, November 9, 2002, at 04:56 AM, bb...@ma... wrote:
>> BTW:  There is nothing app specific about the bootstrap executable.  
>> You don't even need to compile it to use it in another project-- just 
>> add a copy files phase that copies the executable into the 
>> Executables area of the app wrapper and make sure that the executable 
>> name attribute in the info dictionary of the app wrapper is set 
>> correctly.
>
> Yeah, the first thing I tried was a python script as the executable 
> that mirrors bin-python-main.m ie. it calls the python version of 
> exec(). It works without any problems but as you said, there isn't any 
> point.

There might be -- if it allows the bootstrapper to check for the 
presence of a working pyobjc environment without a huge amount of cost, 
that could be very valuable.

Do you happen to have the code around?

>>> I think I know what will help me: a proper build of python. So what 
>>> is recommended? CVS python? Stable python? Fink?
>>
>> Fink rocks.
>
> I haven't got fink for 10.2 yet. How different is it from stable 
> python?

There are two python 2.2 packages in Fink;  with X11 and without.   
Take your pick.   The resulting build isn't different from a stable 
python build except that it does not build with SSL support in the 
socket module [long list of reasons-- some good, some not].  Not a big 
deal;   building the socket module standalone proved to be very easy...

     http://pyobjc.sourceforge.net/software/

>
>>>> In any case, all of this-- the whole execve() style bootstrapper-- 
>>>> is just a hack that'll go away as soon as we have an embeddable 
>>>> build of Python shipping with OS X.
>>>
>>> Yeah, I know. I just had the kluge alert going off in my head and I 
>>> felt compelled to try and fix it. Anything other than the current 
>>> hack is going to be an even bigger hack. You guys have done a great 
>>> job.
>>
>> Thanks.  It just got better.  If you cvs update the pyobjc source 
>> tree, the new Cocoa-Python project template has been cleaned up a 
>> bit.   BTW:  You can create a symlink from /Developer/ProjectBuilder 
>> Extras/Project Templates/... wherever ... to the project template(s) 
>> in the pyobjc source tree directly.   Just make sure you don't end up 
>> w/a .pbxuser file in the template pbproj....
>
> Done.  Main.py is now __main__.py? Good idea. My only problem with the 
> current scheme is that you have to add import statements for your 
> source. Is there away this could be automatically, or better yet 
> dynamically? It would be nice if the user didn't have to touch 
> __main__.py manually. It would be even nicer if __main__.py could 
> figure out where the other stuff is itself.

It would be nice if the __main__.py could have a bunch of the 
repetitive code ripped out.  Wouldn't be hard;  the whole framework 
bootstrapper could be moved to the AppKit module as an extension and 
that is the bulk of the code.

The path setup pretty much has to be done in a context like that-- 
chicken and egg.  Without the path setup, we can't find the pyobjc 
module and, as such, can't move the path setup into PyObjC itself.

The problem with autoloading the code are two fold;   first, there may 
be order dependencies that would be difficult to resolve.  Secondly, it 
is very likely that the developer does not want all of the python files 
loaded!  In particular, the window controller for a preferences panel 
really doesn't need to be loaded until the first time [if they do] the 
user selects the 'Preferences...' menu item.

The situation becomes more complex if the developer needs to load third 
party python modules or NSBundles [or other bits of dynamic code].

b.bum