Python configuration question when python scripts are executed using Appweb as web server.

[IronyOfLife]

On Aug 3, 8:42 pm, "Gabriel Genellina" <gagsl-... at yahoo.com.ar> wrote:
> En Mon, 03 Aug 2009 11:04:07 -0300, IronyOfLife <mydevfor... at gmail.com>  
> escribió:
>
> > I have installed python 2.6.2 in windows xp professional machine. I
> > have set the following environment variables -- PYTHONPATH. It points
> > to following windows folders: python root folder, the lib folder and
> > lib-tk folder.
>
> Why? Did you read it somewhere? Usually there is no need to set the  
> PYTHONPATH variable at all; remove it.
>
> > I have configured IIS to execute python scripts.
>
> > I do not have any issues executing python scripts from the python
> > interpreter window or from the browser using IIS as the web server.
>
> Try again after PYTHONPATH is removed, and make sure you can import all  
> the required modules from the Python console. Only then try to run the cgi  
> scripts.
>
> > However, when I use the open source Appweb web browser to execute
> > python scripts. It is able to execute only simple script without
> > issues. [...]However I am not able to execute python scripts that  
> > contain import
> > statements. I need to point out here that i do not have issue with
> > using os or sys packages. When I tried to execute the sample client
> > script that came with the gnutls wrapper for python, I got error. I
> > narrowed it down to the "from ... import" line in the example.
>
> > from gnutls.crypto import *
> > from gnutls.connection import *
>
> Check that the above lines work fine from inside the Python console.
> If not, something went wrong when you installed the gnutls Python package.
>
> > Next step, in order to debug, I used the module finder to see what is
> > happening. To being with I used the module finder to find out the
> > modules loaded for the simple script hello.py.
>
> Debugging cgi scripts isn't easy sometimes; try adding this line at the  
> start of your script:
>
> import cgitb;cgitb.enable()
>
> You should get a nicely formatted stack trace whenever an exception is  
> raised. If you get an HTTP error instead (like 500 Internal Server Error)  
> it's likely a syntax error, you must fix it before continuing.
> Then, you may find that modulefinder is no more needed.
>
> > import pdb
> > pdb.set_trace()
>
> pdb cannot work inside a CGI script; remove that.
>
> > Once again, let me stress that this issue is happening only when I use
> > appweb as the web server.
>
> I don't know appweb, but if you first make sure the script works from the  
> command line, it should be much easier to make it work in the web server.
>
> --
> Gabriel Genellina

Hi Gabriel

Thanks for your reply.

As I had mentioned in my original post, I am able to successfully
execute gnutls client python script while using python interpreter and
from the web browser while using IIS as web server. The scripts were
not executing successfully only when I used AppWeb as web server.

Setting PYTHONPATH environment variables is mentioned in Python docs.

I figured out how to get the debug statements to write to Appweb logs
and from there I found out the issue to be ImportError. Python does
provide a very cryptic error message. "(<type
'exceptions.ImportError'>, ImportError('DLL load failed: The specified
module could not be found.',), <traceback object at 0x00B61580>)"

I then downloaded filemon (as suggested in another forum) utility tool
for windows environment. Using the tool I found that python.exe is
trying to load gnutls related dlls from system path and a list of
folders (I dont know why it didnt try to pick up the dlls from all the
path provided in PATH environment variable) none of which contain the
gnutls related dlls.

I solved the issue temporarily by copying the gnutls related dlls to
the path searched by python.exe

Now my gnutls client python script executes successfully when i use
Appweb as the web server,

NOTE: When I use python interpreter or IIS as webserver the path where
python.exe looks for gnutls related dll's are different. In this
scenario python.exe is able to successfully load the required dlls.