Turbogears Intergration Issue

[zaf]

Hi, I've followed the docs and tried to deploy my Turbogears web app
with mod_wsgi but when I access it in my browser I get the following
page :
http://pastebin.com/m26db19c7
Can anyone tell me what I'm doing wrong ?
here's my wsgi script :
http://pastebin.com/m5efb0824
Thanks I could really use some help.
Tom

[Graham Dumpleton]

2008/5/7 zaf <Tom.Z...@gmail.com>:

You'll probably get a quicker answer on this one at:

http://groups.google.com/group/turbogears

I've seen them dealing with odd errors like this occasionally.

Usually comes down to incorrect versions of installed packages that TG requires.

Graham

[zaf]

ok I'll ask there, but the odd things is, my tg app works fine if I
start it normally. So I was thinking it probably was a mod_wsgi error.
If anyone can think of anything please let me know.
Tom

On May 7, 1:07 am, "Graham Dumpleton" <graham.dumple...@gmail.com>
wrote:
> 2008/5/7 zaf <Tom.Zaff...@gmail.com>:

[Graham Dumpleton]

Can you provide the Apache configuration related to mod_wsgi. Ie.,
want to know if you are using mod_wsgi daemon mode and running daemon
process as you. If running embedded, or daemon mode but as Apache
users, may not have same permissions as you and thus why it doesn't
work but does when you run it manually.

Graham

2008/5/7 zaf <Tom.Z...@gmail.com>:

[zaf]

here's the current configuration in Apache2 :

WSGIDaemonProcess site-1 threads=25
WSGIProcessGroup site-1
WSGIScriptAlias / /home/tom/cinego/cinego.wsgi

<Directory /home/tom/cinego/>
Order deny,allow
Allow from all
</Directory>

I tried with an without the first two statements but it dodn't change
anything.
I did manage to figure out where the problem comes from though.

In my turbogears app.cfg file (in the config directory) I have
included the turbogears.jsi18nwidget widget and this is what's causing
the error. It's the Javascript that allows localization in Javascript
files so I do need it.
I don't know why it would be causing a problem with mod_wsgi when it's
clearly not if I start the application with the regular start script.
I'm still looking into it. I will let you know if I find out anything.

I have one question by the way : once my app is deployed through
mod_wsgi, I shouldn't need to tweak with the myapp.wsgo file or the
apache conf right ? I can go on developping and not worring about it ?
Thanks for all the help, I was using mod_proxy so far but I want to
use SSL in Apache2 and both don't seem to be compatible. Hope it'll be
easier when I get all this working properly.
Also I disabled the mod_python module. Should it be enabled ? I had
the feeling it would be more likely to collide with mod_wsgi which is
why i unloaded it in the first place.
Tom


On May 7, 9:56 am, "Graham Dumpleton" <graham.dumple...@gmail.com>
wrote:

> Can you provide the Apache configuration related to mod_wsgi. Ie.,
> want to know if you are using mod_wsgi daemon mode and running daemon
> process as you. If running embedded, or daemon mode but as Apache
> users, may not have same permissions as you and thus why it doesn't
> work but does when you run it manually.
>
> Graham
>

> 2008/5/7 zaf <Tom.Zaff...@gmail.com>:

[zaf]

Ok so I still don't know why that doesn't work but I found a simple
enough work around, I just copied over the js file corresponding to
that widget in my static custom js folder and linked to it directly
from my app's template.
It works...
Now I just have to resolve some path changes issues but that should be
simple enough as well.
I still don't understand why that widget wouldn't load.
Thanks for all the help.
Tom

[zaf]

Ok that workaround is actually not working (darn) all it does is
enable the JS but it seems the entire internationalization package in
turbogears won't work behind mod_wsgi.
When I change the language it update the locale variable but the
translated messages are not being loaded.
I'm wondering if there might be a path error or something, maybe it's
looking for those files in the wrong place.
For information they are in the "myapp/locales" directory
This is getting stranger as I play around with it, and I feel like I'm
no closer to finding the solution as I was this morning.

[Graham Dumpleton]

2008/5/7 zaf <Tom.Z...@gmail.com>:

>
> here's the current configuration in Apache2 :
>
> WSGIDaemonProcess site-1 threads=25

Add options for 'user' and 'group' and setting them to the user/group
that you are running TG on command line from. This will determine if
the problem is a result of a permissions problem, ie., Apache user not
being able to access something.

In your account that you run TG from command line, run 'env' command
and work out if you are setting any special environment variables
which you think TG might be relying on for it to work. When running
under Apache it will not have the same environment variables.

You might want to write a very simple WSGI hello world like program
that echos back values from os.environ so you can compare the process
environment variables with what your user account uses.

Graham

[zaf]

> Add options for 'user' and 'group' and setting them to the user/group
> that you are running TG on command line from. This will determine if
> the problem is a result of a permissions problem, ie., Apache user not
> being able to access something.

Ok so I did that, it changed nothing. I though it might be a
permission problem but it doesn't look like it.

>
> In your account that you run TG from command line, run 'env' command
> and work out if you are setting any special environment variables
> which you think TG might be relying on for it to work. When running
> under Apache it will not have the same environment variables.

here's my env output :
http://pastebin.com/m791f33c

>
> You might want to write a very simple WSGI hello world like program
> that echos back values from os.environ so you can compare the process
> environment variables with what your user account uses.
>

And here is what I get from print os.environ in myapp.wsgi file:
{'LANG': 'C', 'PATH': '/usr/local/bin:/usr/bin:/bin', 'PWD': '/home/
tom', 'PYTHON_EGG_CACHE': '/home/tom/cinego/python-eggs', 'HOME': '/
home/tom'}
I tried changing LANG to en_US.UTF-8 and PATH to my env PATH but i
still get the exact same error.
Any other ideas ?
Tom

[zaf]

So I tried getting the env variables from my start-myapp.py script
(the one generated by TG when starting a project) and putting those in
the .wsgi file and it didn't change anything. I still get the same
error.
So it's not the environement variables and it's not a permission issue
as far as I can tell.

[Graham Dumpleton]

2008/5/9 zaf <Tom.Z...@gmail.com>:

>
>
> > Add options for 'user' and 'group' and setting them to the user/group
> > that you are running TG on command line from. This will determine if
> > the problem is a result of a permissions problem, ie., Apache user not
> > being able to access something.
> Ok so I did that, it changed nothing. I though it might be a
> permission problem but it doesn't look like it.

One final thing to try in this area of user environments and
permissions etc. Work out what the current working directory of TG
application is when it is running. Ie. os.getcwd(), then set that same
directory as 'home' option to WSGIDaemonProcess. This will eliminate
any problems due to relative path names being used in your
configuration or code.

Other than that, only sort of problem would interference from
additional shared libraries, plus other Apache modules, that Apache
loads.

Graham

[zaf]

YES that was it thanks !!!
I think I might just do a tutorial on that because of all the time it
took to actually figure this out. Thanks a lot couldn't have done it
without you. I will let you know if I encounter other problems.
Just out of curiosity and in the interest of understanding what I'm
doing, could you tell me why I should use 25 in the threads option of
WSGIDaemonProcess. And I know this is probably written somewhere but
what is the advantage of using that directive and making the app a
daemon ?
Thanks again for the help.
tom

On May 9, 1:09 pm, "Graham Dumpleton" <graham.dumple...@gmail.com>
wrote:
> 2008/5/9 zaf <Tom.Zaff...@gmail.com>:

[Florent Aide]

Graham,

thanks for the effort you took in supporting TurboGears integration
with mod_wsgi. I'll work with TG1 team to make sure we find a fix to
avoid this path problem for i18n support ASAP.

I don't regret forwarding Zaf to your mailing list, even if this has
put some burden on you :p

Florent.

[Graham Dumpleton]

2008/5/9 zaf <Tom.Z...@gmail.com>:

> Just out of curiosity and in the interest of understanding what I'm
> doing, could you tell me why I should use 25 in the threads option of
> WSGIDaemonProcess. And I know this is probably written somewhere but
> what is the advantage of using that directive and making the app a
> daemon ?

Only a daemon process allows you to specify a user that it can run as,
ie., distinct from Apache user that Apache child processes generally
run as. Daemon process mode also allows you to override the initial
current working directory of the process when it is started, and
provided that the one application only runs in it, and it doesn't
change the working directory, generally safe to run code which depends
on current working directory being that directory. In Apache child
processes, because notionally it is a shared system, that is, multiple
applications running, not generally safe to change and/or rely on
current working directory.

As to threads, helps to cut down on memory usage as you can use less
processes to handle same number of concurrent requests. Go have a read
of some of the older articles on my blog about memory usage and also
Python GIL.

Graham