We will first install virtualenv using pip and then create a new environment with the name my_flask_env inside the folder in which we ran the first command. This will create a new folder with the same name:

$ pip install virtualenv
$ virtualenv my_flask_env

Now, from inside the my_flask_env folder, we will run the following commands:

$ cd my_flask_env
$ source bin/activate
$ pip install flask

This will activate our environment and install Flask inside it. Now, we can do anything with our application within this environment, without affecting any other Python environment.

Until now, we have used pip install flask multiple times. As the name suggests, the command refers to the installation of Flask just like any Python package. If we look a bit deeper into the process of installing Flask via pip, we will see that a number of packages are installed. The following is a summary of the package installation process of Flask:

$ pip install -U flask
Downloading/unpacking flask
…........
…........
Many more lines.........
…........
Successfully installed flask Werkzeug Jinja2 itsdangerous markupsafe
Cleaning up...

If we notice carefully, there are five packages installed in total, namely flask, Werkzeug, Jinja2, itsdangerous, and markupsafe. These are the packages on which Flask depends, and it will not work if any of them are missing.

To make our lives easier, we can use virtualenvwrapper, which, as the name suggests, is a wrapper written over virtualenv and makes the handling of multiple virtualenv easier.

$ deactivate

You can install virtualenvwrapper using the following commands:

$ pip install virtualenvwrapper
$ export WORKON_HOME=~/workspace
$ source /usr/local/bin/virtualenvwrapper.sh

In the preceding code, we installed virtualenvwrapper, created a new environment variable with the name WORKON_HOME, and provided it with a path, which will act as the home for all our virtual environments created using virtualenvwrapper. To install Flask, use the following commands:

$ mkvirtualenv flask
$ pip install flask

To deactivate a virtualenv, we can just run the following command:

$ deactivate

To activate an existing virtualenv using virtualenvwrapper, we can run the following command:

$ workon flask

References and installation links are as follows:

In Flask, a configuration is done on an attribute named config of the Flask object. The config attribute is a subclass of the dictionary data type, and we can modify it just like any dictionary.

For instance, to run our application in the debug mode, we can write the following:

app = Flask(__name__)
app.config['DEBUG'] = True

app.debug = True

app.run(debug=True)

There are a bunch of configuration values provided by Flask. We will come across them in the relevant recipes.

As the application grows larger, there originates a need to manage the application's configuration in a separate file as shown here. Being specific to machine-based setups in most cases will most probably not be a part of the version-control system. For this, Flask provides us with multiple ways to fetch configurations. The most frequently used ones are discussed here:

Flask is intelligent enough to pick up only those configuration variables that are written in uppercase. This allows us to define any local variables in our configuration files/objects and leave the rest to Flask.

app = Flask(__name__)
DEBUG = True
TESTING = True
app.config.from_object(__name__)
app.config.from_pyfile('/path/to/config/file')

We can have a default setting base class, and other classes can inherit this base class and override or add deployment-specific configuration variables.

The following is an example of our default setting base class:

class BaseConfig(object):
    'Base config class'
    SECRET_KEY = 'A random secret key'
    DEBUG = True
    TESTING = False
    NEW_CONFIG_VARIABLE = 'my value'

class ProductionConfig(BaseConfig):
    'Production specific config'
    DEBUG = False
    SECRET_KEY = open('/path/to/secret/file').read()

class StagingConfig(BaseConfig):
    'Staging specific config'
    DEBUG = True

class DevelopmentConfig(BaseConfig):
    'Development environment specific config'
    DEBUG = True
    TESTING = True
    SECRET_KEY = 'Another random secret key'

Now, we can use any of the preceding classes while loading the application's configuration via from_object(). Let's say that we save the preceding class-based configuration in a file named configuration.py:

app.config.from_object('configuration.DevelopmentConfig')

So, overall, this makes the management of configurations for different deployment environments flexible and easier.

Flask recommends a specific way to organize static files in our application:

my_app/
    - app.py
    - config.py
    - __init__.py
    - static/
       - css/
        - js/
        - images/
            - logo.png

While rendering them in templates (say, the logo.png file), we can refer to the static files using the following line of code:

<img src='/static/images/logo.png'>

If there exists a folder named static at the application's root level, that is, at the same level as app.py, then Flask will automatically read the contents of the folder without any extra configuration.

Alternatively, we can provide a parameter named static_folder to the application object while defining the application in app.py:

app = Flask(__name__, static_folder='/path/to/static/folder')

In the img src path in the How to do it… section, static refers to the value of static_url_path on the application object. This can be modified as follows:

app = Flask(
    __name__, static_url_path='/differentstatic',
    static_folder='/path/to/static/folder'
)

Now, to render the static file, we will use the following:

<img src='/differentstatic/logo.png'>

<img src='{{ url_for('static', filename="logo.png") }}'>

By default, the instance folder is picked up from the application automatically if we have a folder named instance in our application at the application level:

my_app/
    - app.py
    - instance/
        - config.cfg

We can also explicitly define the absolute path of the instance folder using the instance_path parameter on our application object:

app = Flask(
    __name__, instance_path='/absolute/path/to/instance/folder'
)

To load the configuration file from the instance folder, we will use the instance_relative_config parameter on the application object:

app = Flask(__name__, instance_relative_config=True)

This tells the application to load the configuration file from the instance folder. The following example shows how this will work:

app = Flask(
    __name__, instance_path='path/to/instance/folder',
    instance_relative_config=True
)
app.config.from_pyfile('config.cfg', silent=True)

In the preceding code, first, the instance folder is loaded from the given path, and then, the configuration file is loaded from the file named config.cfg in the given instance folder. Here, silent=True is optional and used to suppress the error in case config.cfg is not found in the instance folder. If silent=True is not given and the file is not found, then the application will fail, giving the following error:

IOError: [Errno 2] Unable to load configuration file (No such file or directory): '/absolute/path/to/config/file'

Refer to the following file structure for a better understanding:

flask_app/
    - run.py
    - my_app/
        – __init__.py
        - hello/
            - __init__.py
            - models.py
            - views.py

First, the flask_app/run.py file will look something like the following lines of code:

from my_app import app
app.run(debug=True)

Then, the flask_app/my_app/__init__.py file will look something like the following lines of code:

from flask import Flask
app = Flask(__name__)

import my_app.hello.views

Then, we will have an empty file just to make the enclosing folder a Python package, flask_app/my_app/hello/__init__.py:

# No content.
# We need this file just to make this folder a python module.

The models file, flask_app/my_app/hello/models.py, has a non-persistent key-value store:

MESSAGES = {
    'default': 'Hello to the World of Flask!',
}

Finally, the following is the views file, flask_app/my_app/hello/views.py. Here, we fetch the message corresponding to the key that is asked for and also have a provision to create or update a message:

from my_app import app
from my_app.hello.models import MESSAGES

@app.route('/')
@app.route('/hello')
def hello_world():
    return MESSAGES['default']


@app.route('/show/<key>')
def get_message(key):
    return MESSAGES.get(key) or "%s not found!" % key


@app.route('/add/<key>/<message>')
def add_or_update_message(key, message):
    MESSAGES[key] = message
    return "%s Added/Updated" % key

We can see that we have a circular import between my_app/__init__.py and my_app/hello/views.py, where, in the former, we import views from the latter, and in the latter, we import the app from the former. So, this actually makes the two modules depend on each other, but here, it is actually fine as we won't be using views in my_app/__init__.py. We do the import of views at the bottom of the file so that they are not used anyway.

We have used a very simple non-persistent in-memory key-value store for the demonstration of the model layout structure. It is true that we could have written the dictionary for the MESSAGES hash map in views.py itself, but it's best practice to keep the model and view layers separate.

So, we can run this app using just run.py:

$ python run.py
* Running on http://127.0.0.1:5000/
* Restarting with reloader

Now, we can see that we have already defined a default message in MESSAGES. We can view this message by opening http://127.0.0.1:5000/show/default. To add a new message, we can type http://127.0.0.1:5000/add/great/Flask%20is%20greatgreat!!. This will update the MESSAGES key-value store to look like the following:

MESSAGES = {
    'default': 'Hello to the World of Flask!',
    'great': 'Flask is great!!',
}

Now, if we open the link http://127.0.0.1:5000/show/great in a browser, we will see our message, which, otherwise, would have appeared as a not-found message.

We will take the application from the previous recipe, Composition of views and models, as a reference and modify it to work using blueprints.

The following is an example of a simple Hello World application using blueprints. It will work in a manner similar to the previous recipe but is much more modular and extensible.

First, we will start with the flask_app/my_app/__init__.py file:

from flask import Flask
from my_app.hello.views import hello

app = Flask(__name__)
app.register_blueprint(hello)

Next, the views file, my_app/hello/views.py, will look like the following lines of code:

from flask import Blueprint
from my_app.hello.models import MESSAGES

hello = Blueprint('hello', __name__)


@hello.route('/')
@hello.route('/hello')
def hello_world():
    return MESSAGES['default']


@hello.route('/show/<key>')
def get_message(key):
    return MESSAGES.get(key) or "%s not found!" % key


@hello.route('/add/<key>/<message>')
def add_or_update_message(key, message):
    MESSAGES[key] = message
    return "%s Added/Updated" % key

We have defined a blueprint in the flask_app/my_app/hello/views.py file. We don't need the application object anymore here, and our complete routing is defined on a blueprint named hello. Instead of @app.route, we used @hello.route. The same blueprint is imported in flask_app/my_app/__init__.py and registered on the application object.

We can create any number of blueprints in our application and do most of the activities that we would do with our application, such as providing different template paths or different static paths. We can even have different URL prefixes or subdomains for our blueprints.

This application will work in exactly the same way as the last application. The only difference is in the way the code is organized.

Installing a Flask app can be achieved very easily using the setuptools library of Python. We will have to create a file called setup.py in our application's folder and configure it to run a setup script for our application. It will take care of any dependencies, descriptions, loading test packages, and so on.

The following is an example of a simple setup.py script for our Hello World application:

#!/usr/bin/env python
# -*- coding: UTF-8 -*-
import os
from setuptools import setup

setup(
    name = 'my_app',
    version='1.0',
    license='GNU General Public License v3',
    author='Shalabh Aggarwal',
    author_email='contact@shalabhaggarwal.com',
    description='Hello world application for Flask',
    packages=['my_app'],
    platforms='any',
    install_requires=[
        'flask',
    ],
    classifiers=[
        'Development Status :: 4 - Beta',
        'Environment :: Web Environment',
        'Intended Audience :: Developers',
        'License :: OSI Approved :: GNU General Public License v3',
        'Operating System :: OS Independent',
        'Programming Language :: Python',
        'Topic :: Internet :: WWW/HTTP :: Dynamic Content',
        'Topic :: Software Development :: Libraries :: Python Modules'
    ],
)

In the preceding script, most of the configuration is self-explanatory. The classifiers are used when we make this application available on PyPI. These will help other users search the application using these classifiers.

Now, we can just run this file with the install keyword as shown here:

$ python setup.py install

This will install this application along with all its dependencies mentioned in install_requires, that is, Flask and all the dependencies of Flask as well. Then, this app can be used just like any Python package in our Python environment.