Question

I’m using django-piston for my REST json api, and I have it all set up for documentation through pistons built in generate_doc function. Under the django runserver, it works great. The template that loops over the doc objects successfully lists the docstrings for both the class and for each method.

When I serve the site via nginx and uwsgi, the docstrings are empty. At first I thought this was a problem with the django markup filter and using restructuredtext formatting, but when I turned that off and just simply tried to see the raw docstring values in the template, they are None.

I don’t see any issues in the logs, and I can’t understand why nginx/uwsgi is the factor here, but honestly it does work great over the dev runserver. I’m kind of stuck on how to start debugging this through nginx/uwsgi. Has anyone run into this situation or have a suggestion of where I can start to look?

My doc view is pretty simple:

views.py

def ApiDoc(request):
    docs = [
        generate_doc(handlers.UsersHandler),
        generate_doc(handlers.CategoryHandler),
    ]

    c = {
        'docs': docs,
        'model': 'Users'
    }

    return render_to_response("api/docs.html", c, RequestContext(request))

And my template is almost identical to the stock piston template:

api/docs.html

{% load markup %}

...

    {% for doc in docs %}

        <h5><a href="#top">top</a></h5>
        <h3><a id="{{doc.name}}">{{ doc.name|cut:"Handler" }}:</a></h3>

        <p>
            {{ doc.doc|default:""|restructuredtext }}
        </p>
...
        {% for method in doc.get_all_methods %}

            {% if method.http_name in doc.allowed_methods %}

            <dt><a id="{{doc.name}}_{{method.http_name}}">request</a> <i>{{ method.http_name }}</i></dt>                

            {% if method.doc %}
                <dd>
                    {{ method.doc|default:""|restructuredtext }}
                <dd>
            {% endif %}

The rendered result of this template under nginx would be that doc.doc and method.doc are None. I have tried removing the filter and just checking the raw value to confirm this.

I’m guessing the problem would have to be somewhere in the uwsgi layer, and its environment. Im running uwsgi with a config like this:

/etc/init/uwsgi.conf

description "uWSGI starter"
start on (local-filesystems
and runlevel [2345])
stop on runlevel [016]
respawn
exec /usr/sbin/uwsgi \
--uid www-data \
--socket /opt/run/uwsgi.sock \
--master \
--logto /opt/log/uwsgi_access.log \
--logdate \
--optimize 2 \
--processes 4 \
--harakiri 120 \
--post-buffering 8192 \
--buffer-size 8192 \
--vhost \
--no-site

And my nginx server entry location snippet looks like this:

sites-enabled/mysite.com

server {
    listen 80;
    server_name www.mysite.com mysite.com;

    set $home   /var/www/mysite.com/projects/mysite;
    set $pyhome /var/www/mysite.com/env/mysite;

    root $home;
...
    location ~ ^/(admin|api)/ {
        include uwsgi_params;
        uwsgi_pass uwsgi_main;

        uwsgi_param UWSGI_CHDIR $home;
        uwsgi_param UWSGI_SCRIPT wsgi_app;
        uwsgi_param UWSGI_PYHOME $pyhome;

        expires epoch;
    }
...
}

Edit: Configuration Info

• Server: Ubuntu 11.04
• uWSGI version 1.0
• nginx version: nginx/1.0.11
• django non-rel 1.3.1
• django-piston latest pypi 0.2.3
• python 2.7

Answer 1

uWSGI is starting up the interpreter in way equivalent to -OO option to Python command line. This second level of optimisation removes doc strings.

-OO    : remove doc-strings in addition to the -O optimizations

Change:

--optimize 2

to:

--optimize 1