Tag Archives: flask

Flask-Admin Hacks for Many-to-Many Relationships

Flask-Admin Many-to-Many Hacks

Flask-Admin is a pretty powerful administration solution, which, however lacks several important features for managing models with many-to-many relationships (or at least clear documentation thereof). Here are some useful (albeit perhaps unreliable) hacks to get Flask-Admin SQLAlchemy models to dance the dance.

Continue reading



Dubugging Flask applications under uWSGI

Flask comes with a fantastic debug mode available with the built-in server, but is advertised as unusable under uWSGI, due to some forking limitations, which I couldn’t understand. There is a way that allows you to spawn the development debug mode in Flask (and Werkzeug) regardless of what everyone around seems to say.

Before the if __name__ == '__main__': part of your application, i.e. at the very end, you have to wrap a werkzeug.debug.DebuggedApplication middleware around your app object.

if ( app.debug ):
    from werkzeug.debug import DebuggedApplication
    app.wsgi_app = DebuggedApplication( app.wsgi_app, True )

That’s it. Simple as that! Debug your Flask application from the browser, without using the built-in development server. Don’t forget to switch off debugging in production, as the console offers arbitrary code execution.

For everything else there’s Winpdb.



Setting up Flask with nginx

I’ve decided to implement one of my next projects in Python. I picked Flask as my HTTP framework for its lightweight and unbinding design. It pretty much allows you to do everything at a low level, should you want to. And I do; I always prefer a low-level approach, without the bulkiness, APIs, configuration files, etc.

In any case, since my webserver of choice has long been nginx (built-in servers don’t impress me too much), having it serve Flask applications in a robust, reliable way was required. The instructions to marry nginx and Flask via uWSGI are quite clear. I compiled the uwsgi application container, read the docs and came up with the following startup command:

sudo uwsgi -s /tmp/uwsgi.application.sock --chdir /path/to/application -w application:app --uid "www-data" --gid "www-data" --touch-reload . --daemonize /var/log/uwsgi.log

The above is a development setting and will probably be very different in production. Since Flask doesn’t force any convention upon you, I picked the following project layout for now:

.
|-- application
|   |-- application.py
|   |-- models
|   |-- routes.py
|   `-- views
`-- static
    |-- favicon.ico
    |-- js
    |   `-- script.js
    `-- robots.txt

All Python code is in the application directory, where uwsgi runs it. Static files are a directory above that, and will be served as from there and not pollute the source tree. I could have kept the static directory under application just as well, but I’ll keep it outside for now. Here’s what I came up for my

server {

    listen 80;
    server_name application.lo www.application.lo;

    root /path/to/application.lo/application;

    try_files /../static/$uri @application;

    location @application {
        include uwsgi_params;
        uwsgi_pass unix:/tmp/uwsgi.application.sock;
    }

}

This is quite suitable for now. Any recommendations?