Re: [Pyobjc-dev] Achieving 1.0....

[Bill B. <bb...@co...>]

On Tuesday, October 22, 2002, at 05:03 PM, Ronald Oussoren wrote:
> On Tuesday, Oct 22, 2002, at 22:47 Europe/Amsterdam, Bill Bumgarner 
> wrote:
> .....
>>
>> I'm pretty happy with the latest incarnation of bin-python-main.m -- 
>> need to commit a new version and update the python project template 
>> -- as it has proven to not be problematic in the production app I'm 
>> working on.   It now supports standalone builds with frameworks 
>> (dynamically loading frameworks with @executable_path as their 
>> install_name AND dependencies on other frameworks w/@executable_path 
>> requires some fun to be had with the environment variables of the 
>> execve() process).
> I'll also have a more serious look bin-python-main.m. I definitely 
> like the idea of just exec-ing a normal python with the right argv.
>
> The only thing I'm not sure about w.r.t. binary distribution of 
> applications is honouring a 'defaults' settings for the location of 
> the python binary. But that is something we can fix in our in-house 
> version of python (we ship extension modules, and those might not work 
> with a different version of python).

It already does that and much, much more!  :-)

See both the main-bin-python.m and the Main.py in the Web Services Tool 
example.   It is the "most correct" version I have created so far and 
will be copied to the other projects / locations soon.  Some of the 
nifty features:

     - auto dumps the pid for attaching to the child python process via 
gdb if SHOWPID is set in the environment

     - correctly sets up environment variables to deal w/linking 
frameworks in production vs. in project builder

     - traverses list of frameworks linked into the main-bin-python.m 
binary and passes 'em off to the Main.py.  Main.py dynamically loads 
each framework, then checks each framework to see if it has an Init.py 
script in Resources/ and executes it, if it does.  I.e. frameworks will 
auto-bootstrap their python stuff as they are loaded into the "real" 
environment.

     - can customize which python binary is used via the PythonBinPath 
user default

     - can customize the Main script used via the main bundles 
PrincipalPythonFile dictionary entry;  defaults to Main.py (should add 
this to the project template, now that I think about it).

     - everything is done w/UTF-8 encoded strings and, as such, should 
work on any OS X installation [as the BSD layer all deals w/UTF-8 
encoded strings for paths and such].

     - setting the DYLD_PRINT_LIBRARIES user default to 1 will cause the 
child python process to dump all of the dylibs as they are loaded

>> I'll try to re-address the documentation on the examples that use 
>> Project Builder and put together a README for the Project Template 
>> stuff.
> Documentation, the mortal enemy of coders :-)

I like using unit tests as documentation, personally.   We [CodeFab] 
have been using XP in varying levels of intensity over the past few 
years.  When it works, it works really well.

b.bum