[Pyobjc-dev] Re: Bootstrapping (Was: Project Templates)

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

On Sunday, Jan 12, 2003, at 12:20 US/Eastern, Dinu Gherman wrote:
> Well, I'm trying to follow what is mandates for running an install
> build on a different (10.1) box with Python in /usr/local/bin. So
> far I tried skipping some of the environment variables, but with no
> luck. In any case, I think I can't assume a non-Python user to go
> through the list in order to run any pyobjc app.

OS X 10.1 doesn't ship with Python, so the user will have to have 
installed some kind of a Python distribution (or the app will need to 
ship with Python in the app wrapper).

In either case, such a distribution will very likely be 'embeddable'.  
That is, will have a library, framework or dynamic-lib such that the 
interpreter can be embedded directly and the app won't have to hunt 
down the python distribution to be used.   As such, you would probably 
want to use the 'Cocoa-Python Application (Embedded Interpreter)' 
template, which doesn't yet exist (but will soon, depending on the 
answer to the question I posed earlier today).

PyObjC doesn't currently support OS X 10.1 anyway.  It would not be 
hard to add -- easier now that GNUstep support has caused the 'build 
this version vs. that version' question to be answered with a concrete 
implementation.

Because one of PyObjC's requirements is to support the build of Python 
that Apple ships with OS X, the default is to go after the python 
binary and do the execve() garbage.   The assumption is also made that 
a python binary exists in /usr/bin/python and that most 
developers/users will never need to change it.

> Could they maybe bootstrap themselves using a shell script that de-
> termines the location of the current Python interpreter and does
> the rest magically before kicking off the app itself?

Yes.   The bin-python-main.m could do exactly that.  It is simply a 
matter of invoking `env python` via popen(), I believe.  Of course, 
that will not pick up a python executable that only appears in the 
user's path in a Terminal environment.   If that fails, a very simple 
binary could be provided that pops an Open Panel and asks the user to 
identify their python binary.  Would not be hard to write, could be 
standardized and could be an added copy phase on the existing app 
projects (or a single source file)....

b.bum