Re: [Pyobjc-dev] Help in bundling our PyObjC app?

[Jack J. <Jac...@cw...>]

On Friday, Jun 13, 2003, at 03:47 Europe/Amsterdam, Gary Robinson wrote:

> Our application will be running a couple of separate "slave" straight 
> Python
> (not Cocoa) scripts to handle some asynchronous tasks. Currently these
> scripts are started and managed with the popen2.Popen4 class.
>
> These slave scripts have to use a version of Python compiled to have 
> SSL
> enabled. So they can't use the stock Python.
>
> I'm wondering if anyone has advice as to how we should put our 
> Cocoa-Python
> app together with these separate scripts in a package for the user.
>
> I envision a bundle that contains the main app and the separate 
> scripts in a
> folder on disk; these all appear to be one unit to the user if I 
> understand
> bundles correctly.
>
> Since the separate scripts need an SSL-enabled Python, is there some 
> way to
> include that Python in the bundle so that the scripts can share it? Or 
> must
> each such script have the SSL Python separately merged into it?

I think (but haven't tried) that you don't need a specially built Python
to enable SSL support, you only need a specially built _socketmodule.so 
extension
module. You can probably put this somewhere in the bundle, but this is 
Advanced
Bundlebuilder so someone else will have to provide the details.

> Question 2:
>
> The bundlebuilder.py script includes the following comment:
>
> # The
> # bootstrapping script fires up the interpreter with the right
> # arguments. os.execve() is used as OSX doesn't like us to
> # start a real new process.
>
> This comment made me feel concerned about our use of popen2.Popen4,
> mentioned above, to start "real new processes". We have had no 
> problems in
> our internal testing, but does anyone know of anything we should worry 
> about
> with this?

Don't worry, the comment doesn't apply in your case. It should be 
clarified.

What the comment tries to say is that the unix process that was started 
when the
user double-clicked the application (and which runs the bootstrap 
script) must be
the same process that later connects to the window manager, otherwise 
the
OSX magic for window manager access doesn't work. This bootstrap code 
ensures that
this is the case for your Cocoa code. Any process you fork off after 
that is a
normal unix process again, i.e. doesn't have access to the window 
manager. But in
your case that is exactly what you want, as your scripts are straight 
python
without any Cocoa code.
--
Jack Jansen, <Jac...@cw...>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman