Re: [Pyobjc-dev] Python rather than ObjC for main?
Brought to you by:
ronaldoussoren
From: Peter M. <zig...@po...> - 2002-11-12 18:06:27
|
On Wednesday, November 13, 2002, at 02:43 AM, bb...@ma... wrote: > 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? Nope, I trashed it. It really wasn't anything special. I just took the Objective-C code and line by line converted it to Python code. I also took a lot of shortcuts such as hardcoding the framework paths send to __main__.py. >>>> 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 that case I'll just download it from www.python.org. OK, done. Hmm... the embeddable library it builds seems to be a static archive. How does one turn that into a dylib? Otherwise it isn't much cheaper code size wise to just including a full python build in the .app wrapper. >> >>>>> 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]. I was just wondering if we could change the way the developer registers their python modules. Either put them in a separate module that __main__.py imports or put the names of the ones you want preloaded into the Info.plist or something like that. I just think it's more professional to not mix user code and essential bootstrap code in the same module. Peter |