Large Applications as Packages

Imagine a simple flask application structure that looks like this:

  1. /yourapplication
  2.     yourapplication.py
  3.     /static
  4.         style.css
  5.     /templates
  6.         layout.html
  7.         index.html
  8.         login.html
  9.         ...

While this is fine for small applications, for larger applications it’s a good idea to use a package instead of a module. The Tutorial is structured to use the package pattern, see the example code.

Simple Packages

To convert that into a larger one, just create a new folder yourapplication inside the existing one and move everything below it. Then rename yourapplication.py to __init__.py. (Make sure to delete all .pyc files first, otherwise things would most likely break)

You should then end up with something like that:

  1. /yourapplication
  2.     /yourapplication
  3.         __init__.py
  4.         /static
  5.             style.css
  6.         /templates
  7.             layout.html
  8.             index.html
  9.             login.html
  10.             ...

But how do you run your application now? The naive python yourapplication/__init__.py will not work. Let’s just say that Python does not want modules in packages to be the startup file. But that is not a big problem, just add a new file called setup.py next to the inner yourapplication folder with the following contents:

  1. from setuptools import setup
  3. setup(
  4.     name='yourapplication',
  5.     packages=['yourapplication'],
  6.     include_package_data=True,
  7.     install_requires=[
  8.         'flask',
  9.     ],
  10. )

In order to run the application you need to export an environment variable that tells Flask where to find the application instance:

BashFishCMDPowershell

  1. $ export FLASK_APP=yourapplication
  1. $ set -x FLASK_APP yourapplication
  1. > set FLASK_APP=yourapplication
  1. > $env:FLASK_APP = "yourapplication"

If you are outside of the project directory make sure to provide the exact path to your application directory. Similarly you can turn on the development features like this:

BashFishCMDPowershell

  1. $ export FLASK_ENV=development
  1. $ set -x FLASK_ENV development
  1. > set FLASK_ENV=development
  1. > $env:FLASK_ENV = "development"

In order to install and run the application you need to issue the following commands:

  1. $ pip install -e .
  2. $ flask run

What did we gain from this? Now we can restructure the application a bit into multiple modules. The only thing you have to remember is the following quick checklist:

  1. the Flask application object creation has to be in the __init__.py file. That way each module can import it safely and the __name__ variable will resolve to the correct package.

  2. all the view functions (the ones with a route() decorator on top) have to be imported in the __init__.py file. Not the object itself, but the module it is in. Import the view module after the application object is created.

Here’s an example __init__.py:

  1. from flask import Flask
  2. app = Flask(__name__)
  4. import yourapplication.views

And this is what views.py would look like:

  1. from yourapplication import app
  3. @app.route('/')
  4. def index():
  5.     return 'Hello World!'

You should then end up with something like that:

  1. /yourapplication
  2.     setup.py
  3.     /yourapplication
  4.         __init__.py
  5.         views.py
  6.         /static
  7.             style.css
  8.         /templates
  9.             layout.html
  10.             index.html
  11.             login.html
  12.             ...

Circular Imports

Every Python programmer hates them, and yet we just added some: circular imports (That’s when two modules depend on each other. In this case views.py depends on __init__.py). Be advised that this is a bad idea in general but here it is actually fine. The reason for this is that we are not actually using the views in __init__.py and just ensuring the module is imported and we are doing that at the bottom of the file.

Working with Blueprints

If you have larger applications it’s recommended to divide them into smaller groups where each group is implemented with the help of a blueprint. For a gentle introduction into this topic refer to the Modular Applications with Blueprints chapter of the documentation.