[Pythonmac-SIG] py2app generated app, not acting as a stand-alone app

[Bob Ippolito]

On Nov 2, 2005, at 11:55 AM, Ronald Oussoren wrote:

> On 2-nov-2005, at 20:38, Richard Rodriguez wrote:
>
>
>> "webdemo.py" opens a cgi server on a port, I'm using port 1770.  It
>> does this by using:  BaseHTTPServer.HTTPServer
>> This allows me to use a web browser, and open a python file, which
>> is generating HTML
>> A browser url would look like:  http://localhost:1770/cgi-bin/
>> test_real3.py
>>
>> So I have 2+ files, "webdemo" and a html page generator
>> "test_real3.py"
>> It seems as if the "webdemo" script, is using the corect "stand-
>> alone" version of python, but the python file that responds to the
>> URL call, seems to be looking in the wrong place.  it's looking at
>> the installed Python, instead of the stand-alone Python.  It could
>> be a path problem of some kind.
>
>
> You didn't quite answer my question :-). How does webdemo execute the
> code in test_real3.py? Does it import it as a module or execute it
> like a real CGI script?
>
> If you execute test_real3.py as a separate process your setup.py
> doesn't work.  Py2app copies just enough of /Libary/Framework/
> Python.framework to supply the dependencies of the script named in
> setup.py (e.g. webdemo.py), and therefore might not include modules
> imported by test_real3.py. I'm amazed that py2app even bothers to
> include bin/python. It definitely does not rewrite the paths to
> shared libraries used by bin/python.

If you set all of the right environment variables, it *almost*  
works.  What really should happen is to place a modified Python  
interpreter in MacOS.. so that the @executable_path ends up right.  I  
could probably just make the bootstrap check to see if it has some  
special name like "python" or "__python__" and act like the  
interpreter in that case.  That might even have a few fringe benefits  
(getting an interpreter that has only access to the contents of your  
app bundle).

I will be starting work on making the Mac OS X Python stack better  
handle universal binaries very soon, and will be making improvements  
to py2app in the process... so I'll probably actually make this  
happen in the next week or two because it's easy and I'll be staring  
at this stuff anyway.

Speaking of which, the svn trunk of py2app should be able to analyze  
and write Mach-O headers of any combination of supported  
architectures now (32-bit of both endians, 64-bit of both endians,  
and the universal header that wraps them).  It's not really tested  
yet, though.

-bob